MIMO Rel-18

 RAN1#109-e

9.1       NR MIMO evolution for downlink and uplink

Please refer to RP-213598 for detailed scope of the WI.

R1-2203886        Work plan for Rel-18 Evolved MIMO       Samsung

9.1.1        Multi-TRP enhancement

9.1.1.1       Unified TCI framework extension for multi-TRP

Including extension for indication of multiple DL/UL TCI states, simultaneous multi-panel UL transmission, and power control for UL single DCI.

R1-2204367        Discussion on unified TCI framework extension for multi-TRP        NTT DOCOMO, INC.

·        Proposal 2-1: Specify joint TCI state and separate UL/DL TCI state to support all of following Rel.16/17 M-TRP schemes:

o   Single/multi-DCI based M-TRP PDSCH NCJT in Rel.16

o   Single-DCI based M-TRP PDSCH repetition with SDM/FDM/TDM in Rel.16

o   M-TRP PDCCH/PUSCH/PUCCH repetition in Rel.17

o   M-TRP inter cell in Rel.17

o   SFN-PDCCH/PDSCH in Rel.17

o   M-TRP BFR in Rel.17

·        Proposal 2-2:

o   The number of “indicated TCI states” can be up to 2 to support Rel.16/17 M-TRP features.

§  If more than 2 TCI states are required in Rel.18, the number of “indicated TCI states” is also increased to support Rel.18 schemes.

o   Specify different signaling mechanism to support unified TCI framework for M-TRP for the following schemes:

§  Single-DCI based M-TRP (for ideal backhaul scenario):

·        One beam indication DCI can indicate up to two “indicated TCI states”.

§  Multi-DCI based M-TRP (for ideal/non-ideal backhaul scenario):

·        One beam indication DCI can indicate one “indicated TCI states” for a TRP.

·        Proposal 2-3: Strive to use one TCI state field (i.e. not adding second TCI state field).

o   Discuss whether to increase the max. number of bits for TCI state field in DCI format 1_1/1_2.

o   Consider RRC configurable size of TCI state field in DCI format 1_1.

·        Proposal 2-4: For unified TCI extension for single-DCI based multi-TRP,

o   For joint TCI state, one TCI codepoint corresponds to up to two joint TCI states.

o   For separate DL/UL TCI state, one TCI codepoint corresponds to up to two DL TCI states and/or up to two UL TCI states.

·        Proposal 2-5: For unified TCI extension for multi-DCI based multi-TRP, definition of CORESETPoolIndex = {0, 1} is reused.

·        Proposal 2-6: For unified TCI extension for multi-DCI based multi-TRP,

o   For joint TCI state, one DCI associated with CORESETPoolIndex = 0 indicates one joint TCI state (1^st indicated TCI state), and the other DCI associated with CORESETPoolIndex = 1 indicates one joint TCI state (2^nd indicated TCI state).

o   For separate TCI state, one DCI associated with CORESETPoolIndex = 0 indicates one DL TCI state and/or one UL TCI state (1^st indicated TCI state), and the other DCI associated with CORESETPoolIndex = 1 indicates one DL TCI state and/or one UL TCI state (2^nd indicated TCI state).

·        Proposal 2-7: For unified TCI extension for multi-DCI based multi-TRP, discuss whether to increase the max. number of RRC configured TCI states from Rel.17.

·        Proposal 3-1: The extension of unified TCI framework can be applied to simultaneous multi-panel PUSCH/PUCCH Tx schemes (if supported). Details can be discussed after the support of simultaneous multi-panel PUSCH/PUCCH transmission schemes is discussed and decided in agenda item 9.1.4.1.

·        Proposal 4-1: For M-TRP operation, with extension of unified TCI framework, per TRP power control can be supported by Rel-17 unified TCI power control framework, i.e., power control parameters are associated with each TCI state.

·        Proposal 4-2: For simultaneous multi-panel PUSCH/PUCCH Tx scheme (if supported), how to determine PCMAX for transmission from each panel can be further studied.

Decision: The document is noted.

R1-2204684         Unified TCI framework extension for multi-TRP        MediaTek Inc.

R1-2203061         Unified TCI framework extension for multi-TRP        FUTUREWEI

R1-2203149         Discussion on unified TCI framework extension for multi-TRP              Huawei, HiSilicon

R1-2203174         Discussion on Unified TCI framework extension for multi-TRP             CEWiT

R1-2203263         Enhancements on unified TCI framework extension for multi-TRP        ZTE

R1-2203320         Discussion on unified TCI framework extension for multi-TRP              Spreadtrum Communications

R1-2203378         On Extension of Unified TCI Framework     InterDigital, Inc.

R1-2203441         On unified TCI framework extension for multi-TRP operation CATT

R1-2203541         Views on unified TCI framework extension for multi-TRP       vivo

R1-2203681         Discussion on unified TCI framework extension for multi-TRP              NEC

R1-2203723         Consideration on Unified TCI framework for multi-TRP          Sony

R1-2203793         Unified TCI framework extension for multi-TRP        xiaomi

R1-2203887         Views on unified TCI extension focusing on m-TRP  Samsung

R1-2203953         Unified TCI framework extension for multi-TRP        OPPO

R1-2204033         Unified TCI framework extension for multi-TRP        Ericsson

R1-2204141         Unified TCI framework extension for multi-TRP/panel            LG Electronics

R1-2204162         Discussion of unified TCI framework for multi-TRP  Lenovo

R1-2204229         Views on unified TCI framework extension for multi-TRP       Apple

R1-2204287         Discussion on unified TCI framework extension for multi-TRP              CMCC

R1-2204440         Discussion on unified TCI framework extension for multi-TRP              ITRI

R1-2204506         Unified TCI framework extension for multi-TRP        Sharp

R1-2204538         Unified TCI framework extension for multi-TRP        Nokia, Nokia Shanghai Bell

R1-2204584         Enhancement on unified TCI framework for multi-TRP            Transsion Holdings

R1-2204678         Multi-TRP enhancements for the unified TCI framework         Fraunhofer IIS, Fraunhofer HHI

R1-2204785         On Unified TCI framework for mTRP           Intel Corporation

R1-2204857         Unified TCI framework extension for multi-TRP        AT&T

R1-2205014         Extension of unified TCI framework for mTRP           Qualcomm Incorporated

R1-2205071         Discussion on unified TCI framework extension for multi-TRP              FGI

R1-2205074         Considerations on unified TCI for mTRP      Fujitsu Limited

[109-e-R18-MIMO-01] – Darcy (MediaTek)

Email discussion on unified TCI framework extension for multi-TRP by May 20

-        Check points: May 12, May 18, May 20

R1-2205225        Moderator summary on extension of unified TCI framework for MTRP (Round 1)           Moderator (MediaTek Inc.)

From May 12^th GTW session

Proposal 1.B-2:

On unified TCI framework extension, support up to 4 indicated TCI states in a CC/BWP for MTRP operation

•          The indicated TCI states are updated by MAC-CE or DCI with the necessary MAC-CE based TCI state activation

•          The UE can be provided with one of the following combinations of indicated TCI states for DL and/or UL MTRP operations in a CC/BWP:

-            1 indicated joint TCI state + 1 indicated joint TCI state

-            1 pair of indicated DL and UL TCI states + 1 pair of indicated DL and UL TCI states

-            1 pair of indicated DL and UL TCI states + 1 indicated DL TCI state

-            1 pair of indicated DL and UL TCI states + 1 indicated UL TCI state

-            FFS: 1 indicated joint TCI state + 1 pair of indicated DL and UL TCI states

-            FFS: 1 indicated joint TCI state + 1 indicated DL TCI state

-            FFS: 1 indicated joint TCI state + 1 indicated UL TCI state

•          FFS: How to provide one of above combinations for a CC/BWP

•          FFS: Details of update and activation for the indicated TCI states for S-DCI based MTRP

•          FFS: Details of update and activation for the indicated TCI states for M-DCI based MTRP

•          FFS: How to map/apply one or more indicated TCI states to a target channel(s)/signal(s)

Decision: As per email decision posted on May 14^th,

Agreement

On unified TCI framework extension, consider all the intra and inter-cell MTRP schemes specified in Rel-16 and Rel-17

·        Consider, if STxMP is supported, Rel-18 MTRP scheme(s) with STxMP

Agreement

On unified TCI framework extension, if an indicated joint or UL TCI state applies to a PUSCH /PUCCH transmission occasion at least for S-DCI based PUSCH/PUCCH repetition with TDM and the indicated joint or UL TCI state is associated with an UL PC parameter setting for PUSCH /PUCCH (including P0, alpha for PUSCH , and closed loop index) and a PL-RS, the UE should apply the UL PC parameter setting and the PL-RS for the PUSCH /PUCCH transmission occasion.

·        FFS: How to extend to other Rel-18 MTRP scheme(s) with STxMP, if supported 

·        FFS: UL PC enhancement for CB and non-CB SRS in above case

FFS: The applied UL PC parameter setting if one or both indicated joint or UL TCI state(s) is not associated with an UL PC parameter setting (including P0, alpha for PUSCH, and closed loop index) for PUCCH/PUSCH

Decision: As per email decision posted on May 20^th,

Agreement

On unified TCI framework extension at least for single-DCI based MTRP, the existing TCI field in DCI format 1_1/1_2 (with or without DL assignment) can indicate multiple joint/DL/UL TCI states in a CC/BWP or a set of CCs/BWPs in a CC list

• FFS: Detail of mapping joint/DL/UL TCI state ID(s) to a TCI codepoint, e.g., possible combinations of joint, DL, and/or UL TCI state IDs that can be mapped to a TCI codepoint
• FFS: Whether to increase the max number of MAC CE activated TCI codepoints, i.e., more than 8 codepoints
• FFS: Whether to increase the max number of TCI field bits, i.e., more than 3 bits
• Note: This doesn't imply that support of one additional TCI field or a field associating the TCI field to the TRP(s) is precluded

Note: The term TRP is used only for the purposes of discussions in RAN1 and whether/how to capture this is FFS

Agreement

On UE power limitation for STxMP for FR2, send LS to RAN4 to check the followings:

• Whether it is feasible to assume power limitation per panel for STxMP (Assumption 1)
• Whether it is feasible to assume a total power limitation per UE over all UE panels used for STxMP (Assumption 2)
• In either of Assumption1 or Assumption 2, whether the total power limitation per UE over all UE panels used for STxMP or the sum of per-panel power limitation for STxMP can be different from (greater than) the existing power limitation for a given power class?
• If both Assumption 1 and Assumption 2 are feasible, whether both assumptions can be applied to a same UE, and what is the relationship between the per-panel power limitation and total power limitation if both are applied (e.g., the sum of per-panel power limitation can be larger than the total power limitation per UE, or should be always the same)?

FFS: Detail of exact LS if agreed

Note: Scenarios of above include at least single carrier scenario for FR2

Note: Above power limitation includes both total radiated power and EIRP

LS to RAN4 (approved on May 24^th, see below).

R1-2205314        Moderator summary on extension of unified TCI framework for MTRP (Round 2)           Moderator (MediaTek Inc.)

From May 20^th GTW session

Agreement

On unified TCI framework extension for M-DCI based MTRP, consider the following alternatives for TCI state update:

·        Alt1: Reuse the same TCI state update scheme for S-DCI based MTRP

·        Atl2: Use the existing TCI field in the DCI format 1_1/1_2 (with or without DL assignment) associated with one of CORESETPoolIndex values to indicate the joint/DL/UL TCI state(s) corresponding to the same CORESETPoolIndex value

·        Alt3: Use the existing TCI field in any DCI format 1_1/1_2 (with or without DL assignment) to indicate all joint/DL/UL TCI states corresponding to both CORESETPoolIndex values

o   Study the association between the indicated joint/DL/UL TCI state(s) and a CORESETPoolIndex value

·        Alt4: Use the existing TCI field in the DCI format 1_1/1_2 (with or without DL assignment) associated with one of CORESETPoolIndex values to indicate joint/DL/UL TCI state(s) corresponding to the same or different CORESETPoolIndex value.

o   Study whether the indicated joint/DL/UL TCI state(s) applies to the channels/signals associated with the same CORESETPoolIndex value or different CORESETPoolIndex value is indicated by DCI

Agreement

On unified TCI framework extension for S-DCI based MTRP, consider at least the following alternatives to map/associate a joint/DL TCI state to PDCCH reception(s)

·        Atl1: Use RRC configuration to inform the mapping/association between a configured or indicated joint/DL TCI state and a CORESET or a CORESET group

·        Alt2: Use RRC configuration to inform the mapping/association between a configured or indicated joint/DL TCI state and a search space set

·        Alt3: Use MAC-CE to inform the mapping/association between an activated or indicated joint/DL TCI state and a CORESET or a CORESET group

·        Alt4: Use DCI to inform the mapping/association between an indicated joint/DL TCI state and a CORESET or a CORESET group

·        Alt5: Based on a fixed mapping/association rule, e.g., the first indicated joint/DL TCI state always applies to PDCCH receptions

Consider above alternatives for PDCCH repetition, PDCCH-SFN, PDCCH w/o repetition/SFN, and potential support of dynamic switching between S-TRP and M-TRP for PDCCH. It is not precluded to adopt one single alternative or multiple alternatives to support these cases.

R1-2205639        LS on UE power limitation for STxMP in FR2        RAN1, MediaTek

Decision: As per email decision posted on May 24^th, the LS is approved.

9.1.1.2       Two TAs for multi-DCI

R1-2203062        Enhancements to support two TAs for multi-DCI  FUTUREWEI

·        Proposal 1: For UL multi-DCI for multi-TRP operation, support two TA offsets (e.g., TRP/panel-specific), and two UL TA reference timings (e.g., TRP-specific).

·        Proposal 2: For UL multi-DCI for multi-TRP operation, support to acquire and maintain Two TA values for multiple TRPs on the same carrier via PRACH enhancement and TA configuration enhancement.

Decision: The document is noted.

R1-2203150         Discussion on TA enhancement for UL M-TRP transmission   Huawei, HiSilicon

R1-2203264         TA enhancement for multi-DCI       ZTE

R1-2203321         Discussion on two TAs for multi-DCI based multi-TRP            Spreadtrum Communications

R1-2203379         Discussion on Multiple TA for multi-TRP    InterDigital, Inc.

R1-2203442         On Two TAs for UL multi-DCI for multi-TRP operation          CATT

R1-2203542         Views on two TAs for multi-DCI-based multi-TRP operation  vivo

R1-2203682         Discussion on two TAs for multi-DCI           NEC

R1-2203724         Considerations on two TAs for multi-DCI    Sony

R1-2203794         Discussion on two TAs for multi-TRP operation         xiaomi

R1-2203888         Views on two TAs for m-DCI          Samsung

R1-2203954         Two TAs for multi-DCI    OPPO

R1-2204034         Two TAs for multi-DCI    Ericsson

R1-2204142         Two TAs for multi-TRP/panel         LG Electronics

R1-2204163         Discussion of two TAs for multi-DCI UL transmission             Lenovo

R1-2204230         On two Timing Advances for multi-DCI Uplink transmissions Apple

R1-2204288         Discussion on two TAs for multi-DCI           CMCC

R1-2204368         Discussion on two TAs for multi-DCI           NTT DOCOMO, INC.

R1-2204507         Two TAs for multi-DCI    Sharp

R1-2204539         Two TAs for UL multi-DCI multi-TRP operation       Nokia, Nokia Shanghai Bell

R1-2204786         On two TAs for multi-DCI Intel Corporation

R1-2205015         Supporting two TAs for multi-DCI based mTRP         Qualcomm Incorporated

[109-e-R18-MIMO-02] – Siva (Ericsson)

Email discussion on two TAs for multi-DCI by May 20

-        Check points: May 12, May 18, May 20

R1-2205209        Moderator Summary #1 on Two TA enhancements for multi-DCI based multi-TRP operation   Moderator (Ericsson)

From May 12^th GTW session

Agreement

Enhancement on two TAs for UL multi-DCI for multi-TRP operation is supported in Rel-18.

·        Note 1: whether (1) the network signals two TACs or (2) the network signals one TAC and the UE deriving the second TA can be further studied.

·        Note 2: evaluations can be considered on as-needed basis.

Agreement

For multi-DCI based multi-TRP operation, down-select one of the two alternatives:

·        Alt 1: configure two TAGs within a serving cell

·        Alt 2: consider two TAs within one TAG within a serving cell

Agreement

Support two TA enhancement for both intra-cell and inter-cell multi-DCI multi-TRP scenarios in Rel-18.

Decision: As per email decision posted on May 15^th,

Agreement

Enhancements on two TAs for UL multi-DCI for multi-TRP operation are applicable to both FR1 and FR2.

Agreement

For multi-DCI multi-TRP operation with two TAs, study the following alternatives:

·        Alt 1: two reference timings are considered

·        Alt 2: one reference timing is considered

Note: reference timing above is the timing of the DL reception

Decision: As per email decision posted on May 19^th,

Agreement

For multi-DCI multi-TRP operation with two TAs, study the following alternatives further in Rel-18:

·           Alt 1: one n-TimingAdvanceOffset value per serving cell

·           Alt 2: two n-TimingAdvanceOffset value per serving cell

Decision: As per email decision posted on May 20^th,

Conclusion

For multi-DCI multi-TRP operation with two TAs, the decision on the maximum uplink timing difference is left up to RAN4.

·        Send an LS to RAN4 asking them the maximum uplink timing difference RAN1 can assume between the two TAs for multi-DCI multi-TRP operation.

Agreement

Two TA enhancement for uplink multi-DCI based multi-TRP operation are applicable to at least:

·        TDM based multi-DCI uplink transmission

·        Simultaneous multi-DCI uplink transmission (if simultaneous uplink multi-DCI uplink transmission is supported in Agenda 9.1.4.1)

·        Note: Whether two TA enhancement is applicable to other schemes is a separate discussion, which is not in the scope of AI 9.1.1.2.

R1-2205592        [Draft] LS on maximum uplink timing difference for Multi-DCI Multi-TRP with two TAs      Ericsson

Decision: As per email decision posted on May 20^th, the draft LS is endorsed. Approved in R1-2205593.

9.1.2        CSI enhancement

Including CSI enhancement for high/medium UE velocities and coherent JT (CJT).

R1-2204540        CSI enhancement for high/medium UE velocities and CJT Nokia, Nokia Shanghai Bell

Hereafter is a summary of proposals for CSI enhancement in high/medium velocities.

Proposal 1              Study the following CSI reporting enhancement schemes for medium/high speed UEs, based on:

·        Reporting of Doppler spread measured by a UE via TRS. The gNB uses the reported Doppler spread to adapt the CSI reporting period and CSI-RS period to a UE’s velocity.

·        Channel prediction at the UE. A UE predicts the channel at one or more future time slots from past CSI-RS measurements and reports one or more predicted PMIs in the same report. The study should include

o   Whether CSI-RS only or a combination of CSI-RS and TRS can be used for prediction

o           Assumption that PMIs in a report share the same  and  

o   CQI reporting based on multiple reported PMIs

·        Precoder prediction at the gNB. A UE reports multiple PMIs calculated from past CSI-RS measurements in one report. The study should include

o   CSI-RS configuration in time

o           Assumption that PMIs in a report share the same  and .  Compression of  in time by using orthogonal basis vectors

o   CQI reporting based on multiple reported PMIs

Proposal 2             For the study of CSI reporting enhancement schemes for medium/high speed UEs based on channel prediction at the UE, consider a case where a UE is configured to report 2 Rel-16 Type-II PMIs in the same CSI report corresponding to future time slots  and , where  is the slot in which the CSI report is received, and  where  is the CSI reporting period.

Proposal 3             For the study of CSI reporting enhancement schemes for medium/high speed UEs based on channel prediction at the UE, consider two alternatives for channel measurement:

·        Single CSI-RS occasion and TRS

·        Multiple CSI-RS occasions

Proposal 4             For the study of CSI reporting enhancement schemes for medium/high speed UEs based on channel prediction at the UE, consider a codebook refinement whereby two PMIs are reported in the same CSI report corresponding to precoders: , for

Proposal 5             For the study of CSI reporting enhancement schemes for medium/high speed UEs based on channel prediction at the UE, consider reporting a single CQI associated to the two PMIs at slot  and , calculated by assuming that the PDSCH transmission lasts  slots and that the PDSCH signal is precoded by  for the first  slots and by  for the second  slots.

Proposal 6             For the study of CSI reporting enhancement schemes for medium/high speed UEs based on precoder prediction at the gNB, consider a  compression scheme whereby  PMIs are reported in the same CSI report corresponding to precoders

, for

where  are the time slots of the latest  CSI-RS measurement occasions, and where  are the elements of an  compression matrix , with .

Proposal 7             For the study of UE’s reporting of time/Doppler information based on TRS measurements, consider the following use cases:

1.       in FDD, UE’s reporting of Doppler spread allows a gNB to adapt the periodicity of CSI reporting or CSI prediction times and the periodicity of CSI-RS to the channel coherence time

2.       in TDD, when full UL/DL channel reciprocity can be assumed, the gNB may use time-correlation or Doppler spectrum reported by a UE to predict the evolution in time of the channel measured from SRS and calculate precoding weights for the PDSCH/DMRS based on the predicted channel.

Proposal 8             For system level performance evaluation of CSI enhancement schemes for medium/high speed UEs, adopt the SLS assumptions from Rel-16 eType-II with the following modifications

Hereafter is a summary of proposals for CJT Type-II enhancement in FDD.

Proposal 9             For the study of Type-II support for CJT in FDD FR1, prioritise enhancement for Rel-16 Type-II regular CB and consider the following aspects

·        Modifications needed to the CSI Reporting Setting

·            Joint or separate determination of codebook components  for different TRPs

Proposal 10           For CJT Type-II reporting in FDD FR1, support the definition of  Port Groups in a CSI Resource Setting configuration, with , according to the following alternatives:

1.       In a Resource Set configured with a single CMR with  ports, a Port Group contains  ports

2.          In a Resource Set configured with  CMRs with  ports each, a Port Group contains the  ports of a CMR.

Proposal 11           For CJT Type-II reporting in FDD FR1 with  TRPs, assume that the total number of beams  in  is network configured. Study whether to support one or both alternatives:

1.          UE selects  beams per TRP

2.          UE selects  beams for TRP , with  and

Proposal 12           For CJT Type-II reporting in FDD FR1 with  TRPs, support UE’s joint selection of  FD basis components of  for all TRPs

Proposal 13           For CJT Type-II reporting in FDD FR1 with  TRPs, study ways to optimise the overlap between the strongest FD basis components of different TRPs, e.g., by introducing a cyclic shift (i.e., phase ramp) for each TRP with respect to a reference TRP.

Proposal 14           For CJT Type-II reporting in FDD FR1 with  TRPs, study ways to reduce the power imbalance between  coefficients of different TRPs, caused by different RSRPs, e.g., by reporting an additional reference amplitude, such as the reference amplitude of the stronger polarisation, for each TRP with respect to the TRP with the strongest coefficient.

Proposal 15           For system level performance evaluation of CSI enhancement schemes for CJT in FDD operations, adopt the SLS assumptions from Rel-16 eType-II with the following modifications

Decision: The document is noted.

R1-2203151         CSI enhancement for coherent JT and mobility           Huawei, HiSilicon

R1-2203229         On CSI enhancements for Rel-18 NR MIMO evolution            Ericsson

R1-2203265         CSI enhancement for high/medium UE velocities and CJT       ZTE

R1-2203322         Discussion on CSI enhancement for coherent JT         Spreadtrum Communications

R1-2203380         Aspects of CSI Enhancements         InterDigital, Inc.

R1-2203443         On Rel-18 CSI enhancements          CATT

R1-2203543         Views on CSI enhancement for high-medium UE velocities and coherent JT       vivo

R1-2203683         Discussion on CSI enhancement     NEC

R1-2203725         Considerations on CSI enhancement for high/medium UE velocities and coherent JT (CJT)     Sony

R1-2203795         Discussion on CSI enhancement     xiaomi

R1-2203890         Views on CSI enhancements           Samsung

R1-2203955         CSI enhancement for high/medium UE velocities and coherent JT         OPPO

R1-2204099         CSI enhancement for high/medium UE velocities and CJT       FUTUREWEI

R1-2204143         Potential CSI enhancement for high/medium UE velocities and coherent JT         LG Electronics

R1-2204164         Discussion of CSI enhancement for high speed UE and coherent JT       Lenovo

R1-2204231         Views on Rel-18 MIMO CSI enhancement   Apple

R1-2204289         Discussion on CSI enhancement for high/medium UE velocities and  CJT               CMCC

R1-2204369         Discussion on CSI enhancement     NTT DOCOMO, INC.

R1-2204508         CSI enhancement Sharp

R1-2204679         CSI enhancements for medium UE velocities and coherent JT Fraunhofer IIS, Fraunhofer HHI

R1-2204691         CSI enhancement for high/medium UE velocities and coherent JT         MediaTek Inc.

R1-2204748         Discussion on CSI Enhancements for high/medium UE velocities and coherent JT               CEWiT

R1-2204787         On CSI enhancements       Intel Corporation

R1-2204858         CSI enhancement AT&T

R1-2205016         CSI enhancements for high-medium UE velocities and Coherent-JT      Qualcomm Incorporated

[109-e-R18-MIMO-03] – Eko (Samsung)

Email discussion on CSI enhancement by May 20

-        Check points: May 12, May 18, May 20

R1-2203889        Moderator summary on Rel-18 CSI enhancements Moderator (Samsung)

Decision: As per email decision posted on May 12^th,

Agreement

On Rel-18 CSI enhancement EVM for SLS, use what is captured in the excel spreadsheet in R1-2205289.

R1-2205289        EVM for Rel-18 MIMO CSI enhancements             Moderator (Samsung)

Agreement

On Rel-18 CSI enhancement EVM for LLS (only for TRS-based TDCP), companies can use the following simulation assumptions:

·        For mTRP 120kmph and over, use Rel-17 HST assumptions (cf. section 2.1 in R1-2007201)

·        For sTRP up to 120km/h:

R1-2205288         Moderator Summary#2 on Rel-18 CSI enhancements: ROUND 2           Moderator (Samsung)

Decision: As per email decision posted on May 12^th,

Agreement

The work scope of Type-II codebook refinement for CJT mTRP includes refinement of the following codebooks:

·       Rel-16 eType-II regular codebook

·        Rel-17 FeType-II port selection (PS) codebook

FFS: Whether to prioritize/down-select from the two

Agreement

The work scope of Type-II codebook refinement for CJT mTRP includes the support of N_TRP={1, 2, 3, 4} cooperating TRPs for CJT CSI report

·        FFS: Signaling of N_TRP, e.g. higher-layer (RRC) vs. dynamic

·        FFS: Determination of N_TRP, e.g. NW-configured vs UE-selected 

·        FFS: Whether to prioritize or only support N_TRP={1, 2}

Agreement

The work scope of Type-II codebook refinement for CJT mTRP includes the following NZP CSI-RS (CMR) setups in Resource Setting associated with Rel-18 Type-II codebook for CJT

·        Opt1: 1 NZP CSI-RS resource, max # ports = 32

o   FFS: whether/how to associate TCI states and CSI-RS ports

·        Opt2: K>1 NZP CSI-RS resources with the same number of ports (representing K TRPs)

o   FFS: The maximum number of ports per resource, and the total number of ports across all resources

FFS: Whether to prioritize/down-select from the two options

Agreement

The work scope of Type-II codebook refinement for CJT mTRP includes down-selecting at least one or merging from the following codebook structures:

·        Alt1A. Per-TRP/TRP group (port-group or resource) SD/FD basis selection + relative co-phasing/amplitude (including WB and/or SB). Example formulation (N = number of TRPs or TRP groups):

o        = co-amplitude and

o        = co-phase

o     Including special case of  (no co-scaling) or

·        Alt1B. Per-TRP/TRP group (port-group or resource) joint SD-FD basis selection + relative co-phasing/amplitude (including WB and/or SB). Example formulation (N = number of TRPs or TRP groups):

o        = co-amplitude and

o        = co-phase

o     Including special case of  (no co-scaling) or

·        Alt2. Per-TRP/TRP group (port-group or resource) SD basis selection and joint (across N TRPs) FD basis selection. Example formulation (N = number of TRPs or TRP groups):

Agreement

The work scope of Type-II codebook refinement for high/medium velocities includes refinement of the following codebooks, based on a common design framework:

·        Rel-16 eType-II regular codebook

·        Rel-17 FeType-II port selection (PS) codebook

FFS: Whether to prioritize/down-select from the two

Agreement

The work scope of Type-II codebook refinement for high/medium velocities includes down selection from the following codebook structures (for discussion purposes):

·        Alt1. Time-domain basis,

o   Alt1A: Time-domain basis commonly selected for all SD/FD bases, e.g.  

o   Alt1B: Time-domain basis independently selected for different SD/FD bases

·        Alt2. Doppler-domain basis

o   Alt2A: Doppler-domain basis commonly selected for all SD/FD bases, e.g.

o   Alt2B: Doppler-domain basis independently selected for different SD/FD bases

o       Note that  may be the identity as a special case

·        Alt3. Reuse Rel-16/17 (F)eType-II codebook with multiple  and a single  and  report.

Agreement

The work scope of Type-II codebook refinement for high/medium velocities includes down selection from the following Doppler-/time-domain basis waveforms for codebook design:

·        Alt1. Orthogonal DFT (with or without rotation factor)

·        Alt2. Oversampled DFT

·        Alt3. Other waveforms, e.g. DCT, Slepian

·        Alt4. Identity (i.e. no Doppler-/time-domain compression)

Agreement

The work scope of Type-II codebook refinement for high/medium velocities includes the following CSI measurement and calculation aspects:

·        Potential refinement on Resource setting configuration on CSI-RS (for CSI and/or tracking) for measuring a burst of CSI-RS, including the applicable time-domain behaviors

·        Whether/how UE-side or gNB-side prediction is assumed for CQI/PMI/RI calculation

·        Potential enhancements on CQI definition and calculation procedure in relation to the PMI of Rel-18 Type-II codebook for high/medium velocities

·        Potential enhancement on definition of CSI reference resource

Agreement

The work scope of TRS-based TDCP reporting focuses on the following use cases for evaluation purposes:

·        Targeting medium and high UE speed, e.g. 10-120km/h as well as HST speed

·        Aiding gNB to determine

o   CSI reporting configuration and CSI-RS resource configuration parameters,

o   Precoding scheme, using one of the CSI feedback based precoding schemes or an UL-SRS reciprocity based precoding scheme

·        Aiding gNB-side CSI prediction

Agreement

The work scope of TRS-based TDCP reporting includes down selection from the following TDCP reporting formats:

·        Alt1. Stand-alone reporting (no inter-dependence with other CSI/UCI parameters)

o   Note: This doesn’t preclude multiplexing with other UCI parameters (e.g. CSI, ACK, SR, …) on PUCCH/PUSCH, if applicable

·        Alt2. Inter-dependent and reported with other CSI parameter(s)

Agreement

The work scope of TRS-based TDCP reporting includes down selection from the following TDCP parameters:

·        Alt1. Doppler shift

·        Alt2. Doppler spread

·        Alt3. Cross-correlation in time

·        Alt4A. Relative Doppler shift of a number of peaks in CIR

·        Alt4B. Relative Doppler shifts of different TRSs

·        Alt5: CSI-RS resource and/or CSI reporting setting configuration assistance

R1-2205362        Moderator Summary#3 on Rel-18 CSI enhancements: ROUND 3    Moderator (Samsung)

From May 16^th GTW session

Agreement

For Rel-18 CSI enhancements, proceed to support and specify the following features (the previously agreed work scopes apply):

·        Type-II codebook refinement for CJT mTRP

·        Type-II codebook refinement for high/medium UE velocities exploiting time-domain correlation/Doppler-domain information

·        UE reporting of time-domain channel properties (TDCP) measured via CSI-RS for tracking

o   The use case of aiding gNB-side CSI prediction is to be confirmed in RAN1#110

R1-2205423        Moderator Summary#4 on Rel-18 CSI enhancements: ROUND 4    Moderator (Samsung)

Decision: As per email thread posted on May 18^th,

Agreement

On the Type-II codebook refinement for CJT mTRP, the resulting codebook(s) are associated with at least the following parameters:

• Parameters for basis reporting, including
• The number of basis vectors: gNB-configured via higher-layer signaling 
• FFS: Whether it is layer-common or layer-specific, whether it is per TRP/TRP-group or common for all TRPs
• Basis selection indicator(s): a part of CSI report
• FFS: Whether it is layer-common or layer-specific, whether it is per TRP/TRP-group or common for all TRPs
• Quantized combining coefficients (W₂): a part of CSI report
• FFS: details of quantization scheme
• Number of non-zero coefficients and bitmap to indicate non-zero coefficients, including whether it is per TRP/TRP-group (separate) or across all TRPs/TRP-groups (joint): a part of CSI report
• Strongest coefficient indicator(s) (SCI(s)): a part of CSI report
• FFS: One per TRP/TRP-group or common for all TRPs
• FFS: Additional need for strongest TRP indicator

Agreement

For the Type-II codebook refinement for CJT mTRP, further study the following issues:

·        The need for the following additional parameters:

o   Receiver side information by per RX reporting or per layer, e.g. information related to the left singular matrix U of the channel

o   Indication of relative offset of reference FD basis per TRP with respect to a reference TRP

o   Information related to the windows for FD basis

o   Delay/frequency difference(s) across TRPs

·        Specification entity corresponding to a TRP (e.g. port-group, NZP CSI-RS resource)

·        For codebooks with per-TRP/TRP-group SD/FD basis (structure Alt1A/1B), whether to support co-amplitude/phase as a part of CSI report (explicit) or not (implicit)

·        Design details of reference amplitudes and differential amplitudes in W₂:

·        Whether/how supported parameter combinations are refined from Rel-16/17

Agreement

On the Type-II codebook refinement for CJT mTRP, down-select from the following TRP selection/determination schemes (where N is the number of cooperating TRPs assumed in PMI reporting):

• Alt1. N is gNB-configured via higher-layer (RRC) signaling
• The N configured TRPs are gNB-configured via higher-layer (RRC) signaling
• Note: only one transmission hypothesis is reported
• Alt2. N is UE-selected and reported as a part of CSI report where N{1,..., N_TRP}
• N is the number of cooperating TRPs, while N_TRP is the maximum number of cooperating TRPs configured by gNB
• In this case, the selection of N out of N_TRP TRPs is also reported (FFS: exact reporting scheme)
• FFS: Configuration of N_TRP TRPs and the value of N_TRP, whether explicit or implicit
• FFS: In addition to one transmission hypothesis, whether reporting multiple transmission hypotheses (with the same N value or possibly different N values) is supported
• Alt3. The UE reports CSI corresponding to K transmission hypotheses
• The N configured TRPs are gNB-configured via higher-layer (RRC) signaling
• FFS: supported value(s) of K, and whether the K transmission hypotheses are gNB-configured or UE-reported

Agreement

On the Type-II codebook refinement for high/medium velocities, for codebook structures with TD or DD basis (Alt1 or Alt2 from codebook structure agreement), the codebook(s) include at least the following additional codebook parameters:

·        Doppler-/time-domain (DD/TD) basis vector length

·        Parameters for DD/TD basis vector selection, including

o   The number of DD/TD basis vectors

o   If applicable, Basis selection indicator(s)

§  FFS: restrictions on the basis vector selection

o   If applicable, the total number of available DD/TD basis vectors (not needed for orthogonal DFT basis set), whether explicitly or implied from another parameter (e.g. oversampling factor)

Agreement

For the Type-II codebook refinement for high/medium velocities, further study the following issues:

• The need for basis type indicator, if both a trivial basis (e.g. identity) and a non-trivial (e.g. DFT) basis are supported, and if so, whether implicit or explicit

·        The need for DD/TD (compression) unit (analogous to PMI sub-band for Rel-16 codebook)

Agreement

On potential refinement of Resource setting configuration associated with Type-II codebook refinement for high/medium velocities, study the following options to assess whether/how the legacy Resource setting configuration needs to be enhanced for “burst” measurement:

·        Periodic (P) CSI-RS: periodicity and offset

·        Semi-persistent (SP) CSI-RS: activation/deactivation, periodicity, and offset

·        Aperiodic (AP) CSI-RS: triggering, offset of a group of AP CSI-RS resources  

FFS: Support for K>1 NZP CSI-RS resources association with Type-II codebook refinement for high/medium velocities

FFS: Whether specification support for jointly utilizing two types of CSI-RS time-domain behaviors is needed

Agreement

The TRS-based TDCP reporting is down selected from the following alternatives:

• Alt1 (stand-alone): TDCP reporting comprises auxiliary feedback information to enable refinement of CSI reporting configuration, and/or codebook configuration parameters, and/or (to be confirmed in RAN1#110) gNB-side CSI prediction
• Aperiodic reporting is supported
• FFS: Whether periodic, semi-persistent and/or event-triggered (UE-initiated) reporting are supported
• Alt2 (non-stand-alone): TDCP reporting corresponds to a subset of the UCI parameters associated with a codebook/PMI for high/medium velocities, reported by the UE and measured via TRS
• FFS: The associated codebook(s)/PMI(s)

R1-2205470        Moderator Summary#5 on Rel-18 CSI enhancements: ROUND 5    Moderator (Samsung)

Decision: As per email decision posted on May 20^th,

Agreement

On the spatial-domain (SD) and frequency-domain (FD) basis design for the Rel-16 Type-II codebook refinement for CJT mTRP, down-select from the following alternatives:

·        Alt1 (separate, legacy DFT): SD basis and FD basis are separate, each fully reusing the legacy Rel-16 DFT-based design

·        Alt2 (joint, DFT): joint SD-FD DFT-based basis

o   FFS: Details on DFT parameters, e.g. length, oversampling (if any), rotation (if any)

·        Alt3 (joint, eigenvector): joint SD-FD eigenvector-based basis

o   FFS: eigenvector codebook design, parametrization

·        Alt4 (separate, eigenvector): SD basis and FD basis are separate, using eigenvector-based basis

o   FFS: eigenvector codebook design, parameterization

Agreement

On the W₂ coefficient quantization scheme for the Type-II codebook refinement for CJT mTRP:

·        At least for N=2, reuse the following components of the legacy Rel-16/17 per-coefficient quantization scheme:

o   Alphabets for amplitude and phase

o   Quantization of phase and quantization of differential amplitude relative to a reference, reference amplitude (with SCI determining the location of one reference amplitude), where the reference is defined for each layer and each “group” of coefficients

·        Further study the following:

o   For larger N values, if supported, whether/how to improve throughput-overhead trade-off using, e.g. lower-resolution alphabets for amplitude and/or phase than legacy, or higher/same resolution alphabets but smaller number of coefficients than legacy

o   What constitutes a “group” (e.g. per polarization across TRPs/TRP-groups, per polarization per TRP/TRP-group, per TRP/TRP-group), the number of “groups” per layer for phase and amplitude (1 ≤C_group,phase ≤ N, 1 ≤ C_group,amp ≤ 2N), and how to indicate/configure “grouping”

Agreement

On the CSI reporting and measurement for the Type-II codebook refinement for high/medium velocities, at least for discussion purposes, define the following:

·        Assume a CSI report in slot n, and let the length of the DD/TD basis vector be N₄

o   Note that basis vector has no span/window in time-domain, only length

·        CSI-RS measurement window of [k,k+W_meas –1], representing the window in which CSI-RS occasion(s) are measured for calculating a CSI report

o   k is a slot index and W_meas is the measurement window length (in slots)

o   Note: In the legacy Rel-16/17 CSI, the CSI-RS occasion(s) are configured in CSI-ReportConfig

·        CSI reporting window of [l,l+W_CSI –1], associated to the CSI report in slot n

o   l is a slot index and W_CSI is the reporting window length (in slots)

·        CSI reference resource(s) in time-domain

o   The location of a CSI reference resource is denoted as n_ref (slot index)

Agreement

On the CSI reporting and measurement for the Type-II codebook refinement for high/medium velocities, consider at least the following alternatives for potential down-selection:

·        Alt1: n_ref (CSI reference resource slot) as boundary

o   Alt1.A: l + W_CSI –1 ≤ n_ref

o   Alt1.B: l ≥ n_ref

o   Alt1.C: l < n_ref and l + W_CSI –1 > n_ref

·        Alt2: n (report slot) as boundary

o   Alt2.A: l + W_CSI –1 ≤ n

o   Alt2.B: l ≥ n

o   Alt2.C: l < n and l + W_CSI –1 > n

·        Alt3: End slot of W_meas (k + W_meas –1) as boundary

o   Alt3.A: l + W_CSI –1 ≤ k + W_meas –1 with the following as a special case: l=k, W_CSI = W_meas

o   Alt3.B: l ≥ k + W_meas –1

o   Alt3.C: l < k + W_meas –1 and l + W_CSI –1 > k + W_meas –1 with the following as special cases:

§  l=k, l + W_CSI = n

§  l=k, l + W_CSI > n

FFS: whether n_ref represents the slot index of Rel-15 CSI reference resource or a newly defined CSI reference resource.

FFS: whether/how the CSI measurement window and reporting window are configured.

9.1.3        Reference signal enhancement

9.1.3.1       Increased number of orthogonal DMRS ports

Including increasing orthogonal DMRS ports for UL/DL MU-MIMO and 8 Tx UL SU-MIMO.

R1-2205112        Increased number of orthogonal DMRS ports        Ericsson              (rev of R1-2203643)

·        Proposal 1: For a UE configured with Rel.18 DMRS, strive for a design that allows a dynamic (e.g. per slot) fall back to using legacy DMRS.

·        Proposal 2: In the new DMRS design, strive for maximizing simultaneous MU-MIMO scheduling of legacy and Rel.18 UEs.

·        Proposal 3:Strive to at least have the same fundamental Rel.18 DMRS design (i.e. as described in 38.211) for DL and UL for a given DMRS Type

·        Proposal 4: Study the use of TD-OCC (Option C) on top of the single symbol DMRS enhancements (Option A and B), to provide an alternative to the channel estimator of separating DM-RS ports in the time domain instead of the frequency domain if delay spread is excessive.

·        Proposal 5: Study solutions and options for Rel.18 DMRS options that creates an issue with Orphan REs, i.e., when the edge of the scheduling bandwidth result in use of fractional length FD-OCC code.

·        Proposal 6: Study antenna port tables and PTRS to DMRS port mapping to support 8 Tx UL SU-MIMO.

Decision: The document is noted.

R1-2203063         Increased number of orthogonal DMRS ports              FUTUREWEI

R1-2203152         Enhancements on DMRS in Rel-18 Huawei, HiSilicon

R1-2203266         DMRS enhancement for UL/DL MU-MIMO and 8 Tx UL SU-MIMO   ZTE

R1-2203323         Discussion on increased number of orthogonal DMRS ports    Spreadtrum Communications

R1-2203381         High Capacity DMRS        InterDigital, Inc.

R1-2203403         Discussions on increased number of orthogonal DMRS ports   New H3C Technologies Co., Ltd.

R1-2203444         On increased number of orthogonal DMRS ports        CATT

R1-2203544         Views on DMRS enhancements      vivo

R1-2203684         Discussion on increased number of orthogonal DMRS ports    NEC

R1-2205159         Discussion on DMRS enhancement xiaomi   (rev of R1-2203796)

R1-2203891         Views on DMRS enhancements      Samsung

R1-2203956         DMRS enhancement for Rel-18 MIMO         OPPO

R1-2204144         Increased number of orthogonal DMRS ports              LG Electronics

R1-2204165         Discussion of increased number of orthogonal  DMRS ports    Lenovo

R1-2204232         Views on supporting increased number of orthogonal DMRS ports        Apple

R1-2204290         Discussion on increased number of orthogonal DMRS ports    CMCC

R1-2204370         Discussion on increased number of orthogonal DMRS ports    NTT DOCOMO, INC.

R1-2204509         Increased number of orthogonal DMRS ports              Sharp

R1-2204541         Rel-18 UL and DL DMRS Enhancements     Nokia, Nokia Shanghai Bell

R1-2204677         Increased number of orthogonal DMRS ports              Fraunhofer IIS, Fraunhofer HHI

R1-2204693         Increased number of orthogonal DMRS ports              MediaTek Inc.

R1-2204788         Discussion on DMRS enhancement Intel Corporation

R1-2205017         Design for increased number of orthogonal DMRS ports          Qualcomm Incorporated

[109-e-R18-MIMO-04] – Yuki (NTT DOCOMO)

Email discussion on increased number orthogonal DMRS ports by May 20

-        Check points: May 13, May 20

R1-2205208        FL summary on DMRS   Moderator (NTT DOCOMO)

Decision: As per email decision posted on May 13^th,

Agreement

·        LLS is used for objective #3 (increasing DMRS ports for MU-MIMO) in Rel.18 MIMO, while SLS can be used optionally.

Agreement

·        No EVM discussion is needed for objective #5 (>4 layers PUSCH DMRS) in AI 9.1.3.1 (DMRS) in Rel.18.

Agreement

·        LLS for increasing DMRS ports in AI 9.1.3.1 in Rel.18:

o   Evaluated channel: PDSCH as baseline (Companies can additionally submit evaluation results of PUSCH).

o   Evaluation metric:

§  BLER for fixed MCS and rank as baseline

§  User throughput for adaptive MCS and rank as optional

§  MSE or NMSE of DMRS as optional

o   Evaluation baseline (i.e. compared with):

§  For evaluation of enhanced single-symbol DMRS, baseline refers to Rel.15 single-symbol DMRS or Rel.15 double-symbol DMRS.

§  For evaluation of enhanced double-symbol DMRS, baseline refers to Rel.15 double-symbol DMRS.

Agreement

·        Following evaluation assumptions are used for LLS for increasing DMRS ports in AI 9.1.3.1 in Rel.18.

Agreement

·        For SLS assumption for increasing DMRS ports in AI 9.1.3.1 in Rel.18,

o   Scenario: Dense Urban (Macro only) at 4GHz is a baseline. Other scenarios (e.g. Umi, Uma) are not precluded.

o   Following evaluation assumptions are used for SLS.

Agreement

·        Specify to increase the max. number of DMRS ports for PDSCH/PUSCH larger than Rel.15 for CP-OFDM without increasing the DMRS overhead.

o   Strive to have common design of DMRS enhancement for PDSCH and PUSCH for a given DMRS Type.

Agreement

·        The maximum number of enhanced DMRS ports in Rel.18 is doubled from Rel.15 DMRS ports:

o   For DMRS type 1, the max. number of enhanced DMRS ports in Rel.18 for PDSCH/PUSCH is

§  Single symbol DMRS: 8 DMRS ports.

§  Double symbol DMRS: 16 DMRS ports.

o   For DMRS type 2, the max. number of enhanced DMRS ports in Rel.18 for PDSCH/PUSCH is

§  Single symbol DMRS: 12 DMRS ports.

§  Double symbol DMRS: 24 DMRS ports.

Agreement

·        To increase the number of DMRS ports for PDSCH/PUSCH, evaluate and, if needed, specify one or more from the following options:

o   Opt.1 (enhance FD-OCC): Introduce larger FD-OCC length than Rel.15 (e.g. 4 or 6).

§  Study aspect includes potential performance degradation in large delay spread, potential scheduling restriction, backward compatibility.

o   Opt.2 (enhance TD-OCC): Utilize TD-OCC over non-contiguous DMRS symbols (e.g. TD-OCC across front/additional DMRS symbols)

§  Study aspect includes potential performance degradation in high UE velocity, potential scheduling restriction (e.g. how to apply freq. hopping), potential DMRS configuration restriction (e.g. restriction of the number of additional DMRS), backward compatibility.

o   Opt.3 (Sparser frequency allocation): increase the number of CDM groups (e.g. larger number of comb/FDM).

§  Study aspect includes potential performance degradation in large delay spread, backward compatibility.

o   Opt.4 (using TDMed DMRS symbol): reusing additional DMRS symbols to increase orthogonal DMRS ports

§  Study aspect includes potential performance degradation in high UE velocity, potential DMRS configuration restriction (e.g. restriction of the number of additional DMRS), backward compatibility. 

o   Opt.5 TD-OCC over non-contiguous DMRS symbols combined with FD-OCC or FDM: reusing additional DMRS symbol(s) to improve channel estimation performance.

§  Study aspect includes potential performance degradation in high UE velocity, potential scheduling restriction (e.g. how to apply freq. hopping), potential DMRS configuration restriction (e.g. restriction of the number of additional DMRS), backward compatibility.

o   The same option can be applied to both single symbol DMRS and double symbol DMRS.

Agreement

·        To increase the max. number of DMRS ports for PDSCH/PUSCH compared to Rel.15 DMRS for CP-OFDM without increasing the DMRS overhead,

o   Study whether/how to enable MU-MIMO between Rel.15 DMRS ports and Rel.18 DMRS ports, as well as whether/how to enable MU-MIMO among Rel.18 DMRS ports, in the same or different CDM group.

R1-2205260        FL summary on DMRS #2             Moderator (NTT DOCOMO)

From May 16^th GTW session

FL proposal#2-1-6a (pre-coding assumption of interference of co-schedules UEs):

For MU-MIMO LLS of PDSCH, the pre-coding assumption of interference of co-schedules UEs is

·        Alt.1: calculated by pre-coder of channel of each co-scheduled UE.

·        Alt.2: random pre-coder.

·        Alt.3: the same pre-coder as scheduled UE.

Companies to report which alternative they are using.

Decision: As per email decision posted on May 19^th,

Agreement

·        For LLS assumptions for increasing DMRS ports in AI 9.1.3.1 in Rel.18:

o   Precoding assumption of PUSCH, “[ZF or SVD]” in RAN1#109e agreement is updated by

§  Alt.2-2: SVD

Agreement

·        To increase the max. number of orthogonal DMRS ports for PDSCH/PUSCH larger than Rel.15

o   Study whether/how to support DCI-based dynamic antenna ports indication of Rel.18 DMRS ports and/or Rel.15 DMRS ports.

o   Study whether/how to reuse the antenna port indication table in 38.212 as much as possible for both PDSCH and PUSCH

o   Study the potential need for MU scheduling restrictions in the design of the enhanced antenna port indication table in 38.212 for DL PDSCH.

Agreement

·        Study the following potential DMRS enhancement for potential support of more than 4 layers SU-MIMO PUSCH. 

o   Extend DMRS port allocation table for rank 5~8 

§  Note: DL DMRS table can be a reference 

o   Enhancement for DMRS to PTRS mapping  

·        Study whether to utilize Rel.18 DMRS ports for more than 4 layers SU-MIMO PUSCH. 

·        Note: the above study does not imply more than 4 layers SU-MIMO PUSCH is supported. 

·        Note: other study for potential DMRS enhancement for potential support of more than 4 layers SU-MIMO PUSCH is not precluded. 

Decision: As per email decision posted on May 20^th,

Agreement

For LLS assumptions for increasing DMRS ports in AI 9.1.3.1 in Rel.18: 

·        Precoding assumption of PDSCH, “[ZF or SVD]” in RAN1#109e agreement is updated by SVD. 

Agreement

·        For MU-MIMO LLS of PDSCH, for evaluation of SVD/CSI-codebook based sub-band precoding, companies shall report the pre-coding assumption of interference of co-scheduled UEs from the following: 

o   Alt.1: calculated by pre-coder of channel of each co-scheduled UE. 

·        For precoding assumption of PDSCH, precoder of target UE and precoder of co-scheduled UE are generated independently.

·        Companies can report a set of azimuth and zenith angle offset used for evaluation (For example, azimuth angle offsets from [30 ^o, 60 ^o, 90 ^o] and zenith angle offset from [3^o, 6^o] can be considered).

o   Alt.2: calculated by random pre-coder (i.e. precoder selected randomly from a predefined set of precoders) which is different from the pre-coder of target UE. 

§  For precoding assumption of PDSCH, only the channel of one target UE, i.e. H_d, needs to be modelled. Precoder is generated based on H_d to obtain the precoder for this UE only. The interference from co-scheduled UEs can be modelled as, , wherein W_i can be randomly selected from a predefined set of precoders

·        Companies shall report how to generate the predefined set of precoders for simulation.

·        Alt.3: the same pre-coder as scheduled UE.

·        PDSCH interference and interfering DMRS ports are emulated using the same pre-coder as for the scheduled UE.

·        Power offset of the co-scheduled UE is one value from {0dB, -3dB, -6dB} as fixed evaluation parameter. Other values are not precluded.

·        For precoding assumption of PDSCH, only the channel of one target UE, i.e. H_d, needs to be modelled. Precoder for the target UE (denoted as W_d) is generated based on H_d only. Denote the precoding matrix/vector of the i^th co-scheduled UEs as W_i, and W_i=W_d (W_i for all th co-scheduled UEs are same). Then the interference from co-scheduled UEs can be modelled as .​

·        For the above Alt.1-3, only PDSCH performance of the target UE is evaluated, while interference of both PDSCH and DMRS of co-scheduled UE(s) is simulated.

Final summary in R1-2205424.

9.1.3.2       SRS enhancement targeting TDD CJT and 8 TX operation

R1-2203153        SRS enhancement for TDD CJT and 8 TX operation in Rel-18         Huawei, HiSilicon

·        Proposal 1: Support SRS enhancement to manage inter-TRP cross-SRS interference for CJT.

·        Proposal 2: Interference randomization enhancement should be supported in R18, e.g., CS hopping.

·        Proposal 3: SRS capacity enhancement should be supported in R18, e.g., capacity enhancement in spatial domain.

·        Proposal 4: Distributing SRS ports in multiple OFDM symbols should be considered for 8-port SRS resource design for better performance of SRS channel estimation.

·        Proposal 5: Multiple SRS pattern should be considered for 8-port SRS resource design.

Decision: The document is noted.

R1-2203066         SRS enhancements for TDD CJT and 8TX operation FUTUREWEI

R1-2203230         On SRS enhancements targeting TDD CJT and 8 TX operation              Ericsson

R1-2203267         SRS enhancement targeting TDD CJT and 8 TX operation       ZTE

R1-2203324         Discussion on SRS enhancement targeting TDD CJT and 8 TX operation               Spreadtrum Communications

R1-2203382         Enhanced SRS Operation  InterDigital, Inc.

R1-2203445         On SRS enhancement        CATT

R1-2203545         Views on SRS enhancement            vivo

R1-2203685         Discussion on SRS enhancement    NEC

R1-2203707         Views on SRS enhancement targeting 8 TX operation KDDI Corporation

R1-2203797         Discussion on SRS enhancements   xiaomi

R1-2203892         Views on SRS enhancements          Samsung

R1-2203957         SRS enhancement targeting TDD CJT and 8 TX operation       OPPO

R1-2204145         SRS enhancement targeting TDD CJT and 8 TX operation       LG Electronics

R1-2204166         Discussion of SRS enhancement     Lenovo

R1-2204233         Views on Rel-18 MIMO SRS enhancement  Apple

R1-2204291         Discussion on SRS enhancement targeting TDD CJT and 8 TX operation               CMCC

R1-2204371         Discussion on SRS enhancement    NTT DOCOMO, INC.

R1-2204510         SRS enhancement targeting TDD CJT and 8 TX operation       Sharp

R1-2204542         SRS enhancement for TDD CJT and 8Tx operation    Nokia, Nokia Shanghai Bell

R1-2204749         Discussion on SRS Enhancements for 8Tx Operation CEWiT

R1-2204789         Discussion on SRS enhancement in Rel-18   Intel Corporation

R1-2205018         SRS enhancement for TDD CJT and 8 Tx operation   Qualcomm Incorporated

[109-e-R18-MIMO-05] – Jialing (Futurewei)

Email discussion on SRS enhancement for TDD CJT and 8 TX by May 20

-        Check points: May 13, May 20

Decision: As per email decision posted on May 14^th,

Agreement

For SRS EVM, adopt combined relevant parts from Rel-17 SRS EVM and Rel-18 FDD CJT EVM as starting point

·        Details are provided in Appendix 3 of R1-2205391 for system-level simulations

·        Details are provided in Appendix 4 of R1-2205391 for link-level simulations.

Agreement

For 8 Tx SRS, a starting point of UE antenna configurations can be:

·        (M, N, P; Mg,Ng; Mp, Np) = (2,2,2; 1,1; 2,2), (dH, dV) = (0.5, 0.5)λ, or

·        (M, N, P; Mg,Ng; Mp, Np) = (1,4,2; 1,1; 1,4), (dH, dV) = (0.5, 0.5)λ.

·        FFS other 8 Tx UE antenna configuration and alignment with outcomes from other agenda items.

R1-2205391        FL Summary #3 on SRS enhancements     Moderator (FUTUREWEI)

From May 16^th GTW session

Proposal 3.2.1-1

Study at least the following for SRS enhancement to manage inter-TRP cross-SRS interference targeting TDD CJT via SRS interference randomization

·        Randomized frequency-domain resource mapping for SRS transmission

o   Including further enhancements to frequency hopping, comb hopping, new frequency-domain resource allocation based on network-provided parameters (this does not change the WI scope)

o   Including introducing new resource mapping not supported in Rel-17

·        Randomized code-domain resource mapping for SRS transmission

o   Including cyclic shift hopping/randomization, sequence hopping/randomization, new code-domain parameter mapping based on system parameters

o   Including introducing new resource mapping not supported in Rel-17

·        Randomized transmission of SRS

o   Including pseudo-random muting of SRS transmission for periodic SRS

·        Per-TRP power control

Decision: As per email decision posted on May 18^th,

Agreement

·        Study the potential enhancements for SRS of 8T8R with usage antennaSwitching.

Decision: As per email decision posted on May 19^th,

Agreement

Study the potential enhancements for SRS for 8 Tx operation

·        SRS resource(s) with 8 ports are configured for codebook-based PUSCH

·        Up to 8 single-port SRS resources are configured for non-codebook-based PUSCH

Agreement

Study the following for SRS enhancement to manage inter-TRP cross-SRS interference targeting TDD CJT via SRS interference randomization and/or capacity enhancement

• Randomized frequency-domain resource mapping for SRS transmission
• E.g., further enhancements to frequency hopping, comb hopping
• Randomized code-domain resource mapping for SRS transmission
• E.g., cyclic shift hopping/randomization, sequence hopping/randomization, per-hop sequence from a long SRS sequence
• Randomized transmission of SRS
• E.g., pseudo-random muting of SRS transmission for periodic and semi-persistent SRS
• Per-TRP power control and/or power control of one SRS towards to multiple TRPs
• SRS TD OCC
• Increasing the maximum number of cyclic shifts
• E.g., multiplying mask sequence to the legacy SRS sequence to effectively increase the maximum cyclic shifts
• Precoded SRS for DL CSI acquisition
• Enhanced signaling for flexible SRS transmission
• E.g., dynamic update of SRS parameters
• Partial frequency sounding extensions
• E.g., larger partial frequency sounding factor, starting RB location hopping enhancements, partial frequency hopping on other bandwidths corresponding to b , besides the last bandwidth
• Enhanced configuration of SRS transmission to enable more efficient SRS parameter assignment
• E.g., configuration of  (sequence index within a group) per SRS resource
• E.g., configuration of cyclic shift per SRS port per SRS resource.
• Resource mapping for SRS transmission based on network-provided parameters or system parameters
• E.g., SRS resource mapping based on network-provided parameters (e.g., configurable indexes) or system parameters (e.g., slot index)

Note: PAPR performance and maintaining DFT waveform property should be considered when deciding the enhancement for Rel-18.

Agreement

Consider the scenario where there exists SRSs sent by a UE and utilized by multiple TRPs for channel estimation, and the pathlosses between the UE and the TRPs differ by at least x dB in Rel-18 SRS study

·        x can be {3,6,10}, and other values can be used.

Decision: As per email decision posted on May 20^th,

Agreement

For SRS enhancements to enable 8 Tx UL operation to support 4 and more layers per UE in UL targeting CPE/FWA/vehicle/Industrial devices, study aspects include, for SRS for CB/NCB/AS,

·        Design parameters, including the maximum number of SRS resource sets, number of SRS resource sets, number of SRS resources, number of ports per resource, number of OFDM symbols, the allowed configurations for comb / comb shifts / cyclic shifts, number of simultaneous ports / resources / resource sets per OFDM symbol

·        For the next decision point, study

o   Whether to support 8 ports in one or multiple resources 

o   Whether to support 8 ports in one or multiple OFDM symbols

o   The maximum number of SRS resource sets.

·        Note: For SRS for NCB, number of ports per SRS resource is still 1 (same as R15)

Decision: As per email decision posted on May 21^st,

Agreement

For SRS EVM, consider additional EVM as follows

·        Realistic channel estimation based on sequence generation for SRS modelling, at least for TDD CJT SRS LLS and 8 Tx SRS LLS as baseline

·        Evaluation metrics for 8 Tx SRS LLS can be MSE , BLER or throughput

·        TDL-C for TDD CJT SRS LLS can be included as optional.

Final summary in R1-2205425.

9.1.4        Enhanced uplink transmission

9.1.4.1       UL precoding indication for multi-panel transmission

R1-2205019        Simultaneous multi-panel transmission     Qualcomm Incorporated

Proposal 1: For single-DCI based simultaneous multi-panel UL transmission, the primary focus should be on SDM / FDM schemes for PUSCH.

·        Further study FDM scheme for PUCCH and SFN schemes for PUSCH/PUCCH.

·        For the agreed schemes, both DG-PUSCH and CG-PUSCH should be supported.

Proposal 2: For single-DCI based PUSCH SDM scheme, support the following

·        Rank combinations 1+1, 1+2, 2+1, and 2+2 similar to Rel-16 SDM PDSCH scheme

·        Two SRS resource sets for codebook based or non-codebook based PUSCH, and SRS resource set indicator in the DCI similar to Rel-17 TDM mTRP PUSCH repetition

o   Two SRI fields in the DCI

o   Two TPMI fields in the DCI (for codebook-based UL)

Proposal 3: For signalling aspects of the single-DCI based PUSCH SDM scheme, identify the differences compared to Rel-16 SDM PDSCH scheme and/or Rel-17 TDM mTRP PUSCH repetition with respect to the following:

·        Mapping DMRS ports to the two beams / TRPs / SRS resource sets.

·        Details of SRI / TPMI signalling in the DCI by two SRI fields / TPMI fields.

Proposal 4: For single-DCI based FDM PUSCH scheme, consider single RV (joint rate matching) and two RVs (repetition).

·        Support two SRS resource sets for codebook based and non-codebook based PUSCH, and reuse Rel-17 mTRP PUSCH repetition signalling for SRI/ TPMI indication and PTRS-DMRS association.

Proposal 5: For simultaneous PUSCH+PUSCH transmission in a same CC with multi-DCI based framework, support DG-PUSCH+DG-PUSCH, CG-PUSCH+CG-PUSCH, and DG-PUSCH+CG-PUSCH.

·        The two PUSCHs that are at least partially overlapping in time domain are associated with different coresetPoolIndex values.

·        For CG-PUSCH, the association with coresetPoolIndex value is determined based on

o   Type 1 CG: RRC configuration per ConfiguredGrantConfig

o   Type 2 CG: coresetPoolIndex value associated with the activation DCI

Proposal 6: For simultaneous PUSCH+PUSCH or PUCCH+PUCCH in the same CC, study different overlap types in time and frequency domain taking into account UE implementations and RF considerations.

Proposal 7: For multi-DCI based PUSCH operation, support two SRS resource sets, where the first SRS resource set is associated with coresetPoolIndex value 0, and the second SRS resource set is associated with coresetPoolIndex value 1.

·        The interpretation of the SRI/TPMI field of the DCI is based on the coresetPoolIndex value of the CORESET in which the DCI is received.

Proposal 8: For simultaneous PUCCH+PUCCH transmission in multi-DCI based multi-TRP, study the impact on UCI multiplexing rules such as performing per coresetPoolIndex value UCI multiplexing.

Proposal 9: Study how to define the maximum output power per CC and across CCs in a given FR (i.e., P_CMAX,f,c and P_CMAX) for simultaneous multi-panel UL transmission. The starting point should be separate and per-panel maximum output power limit.

Proposal 10: Study PHR triggering and reporting for simultaneous multi-panel UL transmission:

·        Joint PHR triggering and reporting should be considered for single-DCI based multi-TRP operation.

·        Separate PHR triggering and reporting can be considered for multi-DCI based multi-TRP operation.

Proposal 11: For SLS simulation assumptions, support Table 1 as baseline.

Decision: The document is noted.

R1-2203154         Discussion on UL precoding indication for multi-panel transmission     Huawei, HiSilicon

R1-2203268         Enhancements on UL precoding indication for multi-panel transmission              ZTE

R1-2203325         Discussion on UL precoding indication for multi-panel transmission     Spreadtrum Communications

R1-2203383         Precoding for Uplink Multi-panel   InterDigital, Inc.

R1-2203446         On UL precoding indication for multi-panel transmission         CATT

R1-2203546         Views on UL precoding indication for multi-panel transmission             vivo

R1-2203686         Discussion on UL precoding indication for multi-panel transmission     NEC

R1-2203726         Considerations on UL precoding indication for multi-panel transmission               Sony

R1-2203798         Enhancements on multi-panel uplink transmission      xiaomi

R1-2203893         Views on UL precoding indication for STxMP            Samsung

R1-2203958         Transmission scheme and UL precoding indicaton for multi-panel transmission               OPPO

R1-2204146         UL precoding indication for multi-panel transmission LG Electronics

R1-2204167         UL precoding indication for multi-panel transmission Lenovo

R1-2204234         Views on UL precoding indication for multi-panel simultanous PUSCH transmissions       Apple

R1-2204292         Discussion on UL precoding indication for multi-panel transmission     CMCC

R1-2204372         Discussion on multi-panel transmission        NTT DOCOMO, INC.

R1-2204511         Views on UL multi-panel transmission         Sharp

R1-2204543         UL precoding indication for multi-panel transmission Nokia, Nokia Shanghai Bell

R1-2204685         UL precoding indication for multi-panel transmission MediaTek Inc.

R1-2204790         UL precoding indication for multi-panel transmission Intel Corporation

R1-2204875         UL precoding indication for multi-panel transmission Ericsson

//This one is to use NWM – please use RAN1-109-e-NWM-R18-MIMO-06 as the document name

[109-e-R18-MIMO-06] – Li (OPPO)

Email discussion on UL precoding indication for multi-panel transmission by May 20

-        Check points: May 13, May 20

Decision: As per email decision posted on May 16^th,

Agreement

For STxMP PUSCH in single-DCI based mTRP system, study and evaluate the following schemes for PUSCH:

• SDM scheme: different layers/DMRS ports of one PUSCH are separately precoded and transmitted from different UE panels simultaneously.
• Study and evaluate whether to support 2 CWs in SDM manner and transmitted from two different panel simultaneously.
• FDM-B scheme: two PUSCH transmission occasions with same/different RV of the same TB are transmitted from different UE panels on non-overlapped frequency domain resources and the same time domain resources.
• FDM-A scheme: different parts of the frequency domain resource of one PUSCH transmission occasion are transmitted from different UE panels.
• SFN-based transmission scheme: all of the same layers/DMRS ports of one PUSCH are transmitted from two different UE panels simultaneously.
• SDM repetition scheme: two PUSCH transmission occasions with different RV of the same TB are transmitted from two different UE panels simultaneously.

Note: Companies are encouraged to evaluate the different schemes for possible down-selection in RAN1#110.

Note: other schemes are not precluded

R1-2205407        Summary on UL precoding indication for multi-panel transmission Moderator (OPPO)

From May 18^th GTW session

Agreement

For the EVM of STxMP of Rel-18

·        Reuse the SLS assumption of BM/Multi-panel UE in R1-2007151 with necessary update, as shown in Table A1

·        Reuse the LLS assumption of Rel-17 mTRP UL repetition transmission with necessary update, as shown in Table A2

·        Note: company can evaluate FR1 and explain the details of EVM assumptions for that

Table A1: SLS assumption for STxMP of Rel-18

Table A2: LLS assumption for STxMP of Rel-18

R1-2205528         Summary #2 on UL precoding indication for multi-panel transmission  Moderator (OPPO)

R1-2205529        Summary of [109-e-R18-MIMO-06] Email discussion          Moderator (OPPO)

From May 20^th GTW session

Agreement

For multi-DCI based STxMP PUSCH+PUSCH transmission, study and evaluate the following aspects:

·        Two PUSCHs are associated with different TRPs and transmitted from different UE panels. The total number of layers of these two PUSCHs is up to 4.

·        Study STxMP of PUSCH+PUSCH transmission where it is some combination of DG-PUSCH, CG-PUSCH and msg3/msgA PUSCH.

·        The overlapping type(s) of fully/partially in time domain and fully/partially/non-overlapping in frequency domain are to be studied and justified for PUSCH+PUSCH.

Note: The above study shall take into account the UE implementation and RF considerations.

Note: Study the conditions required for STxMP PUSCH+PUSCH.

Note: Other aspects are not precluded.

Agreement

Study the enhancement of SRS resource set configuration and SRI/TPMI indication for single-DCI based STxMP PUSCH scheme:

• The configuration of two SRS resource sets, SRS resource set indicator field, two SRI fields and two TPMI fields of Rel-17 mTRP PUSCH TDM repetition is the starting point.
• FFS: The configuration of one SRS resource set, one or two SRI fields and one or two TPMI fields
• Note: This proposal does not mean that any possible SRI/TPMI enhancement on STxMP would be precluded. In RAN1#110, companies can suggest the detail SRI/TPMI enhancement with reasonable analysis and evaluation result.

Agreement

Study the layer combinations of {1+1, 1+2, 2+1, 2+2} for the SDM scheme (if supported) of single-DCI based STxMP PUSCH,

• This is for 1 CW at least.
• The layer combination for the SDM scheme can be further studied for 2 CW if 2 CW in SDM scheme is supported.
• FFS: study the layer combinations of {1+3, 3+1} under the above conditions.
• Companies are encouraged to provide SLS/LLS for their proposed layer combinations for the SDM scheme of single-DCI based STxMP PUSCH.

Agreement

Study if any enhancement is needed on DMRS port indication for the SDM scheme (if supported) of single-DCI based STxMP PUSCH

·        FFS how to map DMRS ports to two joint/UL TCI states/CWs/panels/TRPs/SRS resource sets/PUSCH layers for codebook-based and non-codebook based PUSCH respectively.

Final summary in R1-2205598.

9.1.4.2       SRI/TPMI enhancement for enabling 8 TX UL transmission

To support up to 4 or more layers per UE in UL targeting CPE/FWA/vehicle/industrial devices.

R1-2203269        SRI/TPMI enhancement for enabling 8 TX UL transmission             ZTE

Proposal 1: Regarding 8 Tx-UL operation in Rel-18, support 8-TX and more than 4 layers UL transmission.

Proposal 2: Both codebook based and non-codebook based UL transmission should be supported in Rel-18 for UL MIMO.

Proposal 3: Full coherent and partial coherent capabilities should be supported, and non coherent capability can be precluded or deprioritized in Rel-18 for UL MIMO.

Proposal 4: On 8-Tx UL transmission enhancement, 2 CWs for UL transmission should be supported.

-         Condition of enabling >1 CWs for UL transmission can be further studied in RAN1, e.g., if the number of TX(s) and the number of UL layers exceed threshold(s).

Proposal 5: The legacy full power mode 1 and 2 should be supported in Rel-18 for UL MIMO, but details can be discussed after codebook design is clear.

Proposal 6: Antenna layout assumption for partial coherent codebook should be determined before codebook design.

Proposal 7: Regarding 8-Tx full coherent codebook design, the following schemes can be considered

-          Scheme 1: reusing DL type I 8Tx codebook scheme

-          Scheme 2: UL 4Tx codebook + additional phase

Proposal 8: Regarding 8-Tx partial coherent codebook design, the following schemes can be considered

-          Scheme 1: 8-port full coherent codebook indication + puncture pattern indication (indicating zero-power elements in a matrix)

-          Scheme 2: Multiple port groups, with common or separate precoding information indication

Proposal 9: Regarding non codebook based transmission design for 8-Tx,

-          The number of SRS resources in an SRS set can be up to 8

-          Potential optimization for SRI re-design considering DCI overhead, e.g., 8 bits or less

Proposal 10: Regarding CW-to-layer mapping, support up to 2 CWs for UL 8-Tx transmission, and then further study the following aspects:

-          Scrambling, layer mapping, and DCI format to support second TB

-          Code rate and TB size when UCI is transmitted on PUSCH

Decision: The document is noted.

R1-2203155         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               Huawei, HiSilicon

R1-2203326         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               Spreadtrum Communications

R1-2203384         On SRI/TPMI Enhancement            InterDigital, Inc.

R1-2203447         On SRI/TPMI enhancement for UL 8 TX      CATT

R1-2203547         Views on enabling 8 TX UL transmission     vivo

R1-2203687         Discussion on SRI/TPMI enhancement         NEC

R1-2203727         Considerations on TPMI enhancement for UL transmission     Sony

R1-2203799         Enhancements on 8Tx uplink transmission   xiaomi

R1-2203894         Views on TPMI/SRI enhancements for 8Tx UL transmission   Samsung

R1-2203959         SRI TPMI enhancement for 8 TX UL transmission    OPPO

R1-2204147         SRI/TPMI enhancement for enabling 8 TX UL transmission    LG Electronics

R1-2204168         SRI/TPMI enhancement for enabling 8TX UL transmission     Lenovo

R1-2204235         Views on SRI/TPMI enhancement for enabling 8 TX UL transmission  Apple

R1-2204293         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               CMCC

R1-2204373         Discussion on 8 TX UL transmission            NTT DOCOMO, INC.

R1-2204512         Views on 8 TX UL transmission     Sharp

R1-2204544         UL enhancements for enabling 8Tx UL transmission Nokia, Nokia Shanghai Bell

R1-2204692         SRI/TPMI enhancement for enabling 8 TX UL Transmission   MediaTek Inc.

R1-2204791         Discussion on enhancement for 8Tx UL transmission Intel Corporation

R1-2204876         SRI/TPMI enhancement for enabling 8 TX UL transmission    Ericsson

R1-2205020         Enhancements for 8 Tx UL transmissions     Qualcomm Incorporated

[109-e-R18-MIMO-07] – Afshin (InterDigital)

Email discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission by May 20

-        Check points: May 13, May 20

R1-2205220         FL Summary on SRI/TPMI Enhancements; First Round           Moderator (InterDigital)

Decision: As per email decision posted on May 13^th,

Agreement

Study fully-coherent, partially-coherent and non-coherent UEs for uplink transmission with 8TX UEs.

Agreement

Study full power transmission for 8TX UEs.

·        Details are FFS upon completion of codebook design

Decision: As per email decision posted on May 18^th,

Agreement

Adopt the following Table as the reference EVM for LLS evaluation

·        Companies may provide additional evaluation results per their case of interest

·        LLS is optionally used for 8Tx UL evaluation, if needed

Agreement

For 8TX UE uplink transmission, study codebook- and non-codebook-based transmission with maximal layer number of both 4 and 8 layers.

R1-2205221        FL Summary on SRI/TPMI Enhancements; Second Round Moderator (InterDigital)

Decision: As per email decision posted on May 19^th,

Agreement

·        Adopt the following Table as the reference EVM for SLS evaluation.

o   Companies may provide additional evaluation results per their case of interest.

R1-2205497        FL Summary on SRI/TPMI Enhancements; Third Round  Moderator (InterDigital)

From May 20^th GTW session

Agreement

For 8TX UE, consider the following UE antenna layouts for codebook design,

• For non-coherent UEs, consider linear array (1D/2D) of cross-polarized or single-polarized antenna configuration

·        For fully/partial-coherent UEs, consider linear array (1D/2D)

o   Where the array is either cross-polarized antenna configuration or single polarized antenna configuration

o   Ng>=1 antenna groups can be considered where each group comprises coherent antennas, and across groups, antennas can be non-coherent/coherent depending on device types

§  An example of an antenna group is a panel

o   Within an antenna group, antenna elements are uniformly spaced. Across different antenna groups, companies to provide details.

Additional information for definition of antenna layout

·        Based on the number of coherent groups, following exemplary cases can be considered where, within each group, antenna elements are spaced by 0.5λ, and then dG-H, dG-V represent the horizontal and vertical spacings between the centers of adjacent antenna groups, respectively

o   Further down-selection can be done in the next meeting, if needed

o   The shown exemplary placing of antenna groups can be used for evaluation purpose, but the codebook design is not restricted to shown cases.

o   Other antenna layouts for other use cases are not precluded.

o   To start companies may report their results according to their preferred layout.

·        Other UE antenna assumption for the purpose of evaluation

Decision: As per email decision posted on May 20^th,

Agreement

For 8TX UE codebook-based uplink transmission, down-select one of

·        Alt1-a:

o   Study NR Rel-15 UL 2TX/4TX codebooks and/or 8x1 antenna selection vector(s) as the starting point for design of the codebook for non-coherent UEs

o   Study NR Rel-15 DL Type I codebook as the starting point for design of the codebook for fully/partially-coherent UEs

·        Alt1-b:

o   Study NR Rel-15 UL 2TX/4TX codebooks and/or 8x1 antenna selection vector(s) as the starting point for design of the codebook for partially/non-coherent UEs

o   Study NR Rel-15 DL Type I codebook as the starting point for design of the codebook for fully-coherent UEs

·        Alt2-a:

o   Study NR Rel-15 UL 2TX/4TX codebooks and/or 8x1 antenna selection vector(s) as the starting point for design of codebook for fully/partially/non-coherent UEs

·        Alt2-b:

o   Study NR Rel-15 UL 2TX/4TX codebooks and/or 8x1 antenna selection vector(s) in combination with those based on NR Rel-15 DL Type I codebooks as the starting point for design of codebook for fully/partially/non-coherent UEs

·        Alt3:

o   Study NR Rel-15 DL Type I codebook as the starting point for design of codebook for fully/partially/non-coherent UEs

·        Transmission using one or multiple precoders corresponding to one or multiple SRS resources can be studied as part of the above alternatives.

Final summary in:

R1-2205587        Recommended Direction on SRI/TPMI Enhancements for RAN1#110               Moderator (InterDigital, Inc.)

9.1.55        Other

R1-2203270         Evaluation assumptions for CSI, simultaneous multi-panel UL transmission and 8-Tx UL operation       ZTE

R1-2203548         Discussion on CSI prediction at UE vivo

R1-2203895         Initial SLS results on Type-II CSI enhancements for CJT         Samsung

R1-2204236         Views on MIMO further enhancement          Apple

R1-2204877         Further elaboration on UL evaluations          Ericsson

R1-2204913         Discussion on field test results of CSI enhancement for coherent JT       Huawei, HiSilicon

 RAN1#110

9.1       NR MIMO evolution for downlink and uplink

Please refer to RP-213598 for detailed scope of the WI.

[110-R18-MIMO] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Eko (Samsung)

9.1.1        Multi-TRP enhancement

9.1.1.1       Unified TCI framework extension for multi-TRP

Including extension for indication of multiple DL/UL TCI states, simultaneous multi-panel UL transmission, and power control for UL single DCI.

R1-2205747         Unified TCI framework extension for multi-TRP        FUTUREWEI

R1-2205816         Discussion on Unified TCI Extension for MTRP         InterDigital, Inc.

R1-2205825         Discussion on unified TCI framework extension for multi-TRP operation            TCL Communication Ltd.

R1-2205879         Discussion on unified TCI framework extension for multi-TRP              Huawei, HiSilicon

R1-2205918         Enhancements on unified TCI framework extension for multi-TRP        ZTE

R1-2205981         Discussion on unified TCI framework extension for multi-TRP              Spreadtrum Communications

R1-2206024         Discussion on unified TCI framework extension for multi-TRP              vivo

R1-2206110         Considerations on unified TCI framework for multi-TRP         Sony

R1-2206161         Discussion on unified TCI extension for mTRP           Fujitsu

R1-2206209         Discussion of unified TCI framework for multi-TRP  Lenovo

R1-2206246         Unified TCI framework extension for multi-TRP        Ericsson

R1-2206263         Unified TCI framework extension for multi-TRP        OPPO

R1-2206375         Discussion on unified TCI framework extension for multi-TRP operation               CATT

R1-2206463         Discussion on unified TCI framework extension for multi-TRP              NEC

R1-2206484         Discussion on unified TCI framework extension for multi-TRP              Google

R1-2206570         Unified TCI framework for mTRP  Intel Corporation

R1-2206620         Unified TCI framework extension for multi-TRP        Xiaomi

R1-2206667         Enhancement on unified TCI framework for multi-TRP            Transsion Holdings

R1-2206810         Views on unified TCI extension focusing on m-TRP  Samsung

R1-2206866         Unified TCI framework extension for multi-TRP/panel            LG Electronics

R1-2206894         Discussion on unified TCI framework extension for multi-TRP              CMCC

R1-2206975         Multi-TRP enhancements for the unified TCI framework         Fraunhofer IIS, Fraunhofer HHI

R1-2206995         Unified TCI framework extension for multi-TRP        MediaTek Inc.

R1-2207065         Discussion on Unified TCI framework extension for multi-TRP             CEWiT

R1-2207096         Discussion on unified TCI framework extension for multi-TRP              FGI

R1-2207215         Extension of unified TCI framework for mTRP           Qualcomm Incorporated

R1-2207265         "Unified TCI framework extension for multi-TRP      "             Panasonic

R1-2207320         Unified TCI framework extension for multi-TRP        Apple

R1-2207393         Discussion on unified TCI framework extension for multi-TRP              NTT DOCOMO, INC.

R1-2207444         Discussion on unified TCI framework extension for multi-TRP              ITRI

R1-2207450         Unified TCI framework extension for multi-TRP        Sharp

R1-2207544         Unified TCI framework extension for multi-TRP        Nokia, Nokia Shanghai Bell

R1-2207735        Moderator summary on extension of unified TCI framework (Round 0)               Moderator (MediaTek Inc.)

From Monday session

Agreement:

On unified TCI framework extension for S-DCI based MTRP, to inform the association with the joint/DL TCI state(s) indicated by DCI/MAC-CE for PDCCH repetition, PDCCH-SFN, and PDCCH w/o repetition/SFN, down-selection at least one alternative from the followings:

• Alt1-1: Use RRC parameter(s) in a CORESET configuration to inform the UE whether and/or which indicated joint/DL TCI state(s) shall be applied to the corresponding PDCCH receptions on the CORESET
• FFS: Whether only the CORESET(s) that always/can share the unified TCI state as defined in Rel-17 unified TCI framework can be associated with the joint/DL TCI state(s) indicated by DCI/MAC-CE
• Alt1-2: Use an RRC parameter in a CORESET configuration to inform that the CORESET belongs to which CORESET group(s), and the indicated joint/DL TCI state(s) is associated with each CORESET group
• FFS: Whether only the CORESET(s) that always/can share the unified TCI state as defined in Rel-17 unified TCI framework can be associated with the CORESET group(s)
• FFS: How to associate the indicated joint/DL TCI state(s) with each CORESET group
• FFS: The UE applies the indicated joint/DL TCI state(s) to a CORESET according to the CORESET group(s) the CORESET belongs to, or the UE applies the indicated joint/DL TCI state(s) associated with the CORESET group(s) in which the beam indication DCI is received to all PDCCH receptions
• Alt2: The association between a CORESET and the indicated joint/DL TCI state(s) is determined based on a fixed rule, and the UE shall apply the indicated joint/DL TCI state(s) to the corresponding PDCCH receptions on the CORESET
• FFS: Whether only the CORESET(s) that always/can share the unified TCI state as defined in Rel-17 unified TCI framework can be associated with the joint/DL TCI state(s) indicated by DCI/MAC-CE
• Alt3: Use MAC-CE to inform the UE whether and/or which indicated joint/DL TCI state(s) shall be applied to the corresponding PDCCH receptions on a CORESET
• FFS: Whether only the CORESET(s) that always/can share the unified TCI state as defined in Rel-17 unified TCI framework can be associated with the joint/DL TCI state(s) indicated by DCI/MAC-CE

Switching between multi-TRP and single TRP operation is not precluded.

R1-2207928        Moderator summary on extension of unified TCI framework (Round 1)               Moderator (MediaTek Inc.)

R1-2208075        Moderator summary on extension of unified TCI framework (Round 2)               Moderator (MediaTek Inc.)

From Thursday session

Agreement

On unified TCI framework extension, at least for the target use cases agreed in RAN1#109-e in AI 9.1.1.1, up to 4 TCI states can be indicated in a CC/BWP or a set of CCs/BWPs in a CC list to DL receptions and/or UL transmissions, where these TCI states are indicated/updated by MAC-CE/DCI with the necessary MAC-CE based TCI state activation

·        FFS: The possible combination(s) of joint/DL/UL TCI states that can be indicated to DL receptions and/or UL transmissions in a BWP/CC/TRP

·        Note: This agreement does not imply that there will be more than 2 DL or UL or joint TCI states indicated in a CC/BWP for the target use cases agreed in RAN1#109-e in AI 9.1.1.1

·        Note: The maximum number of TCI states that can be indicated to each of the target use cases agreed in RAN1#109-e in AI 9.1.1.1 is remained the same as in Rel-16/17

Note: The maximum number of TCI states that can be indicated simultaneously to CJT-based PDSCH reception and the required type(s) of TCI states (i.e., DL /UL/joint) are independently discussed in this AI

Agreement

On unified TCI framework extension for S-DCI based MTRP, for PUSCH transmission scheduled/activated by a DCI format 0_1/0_2, down-selection one alternative from the followings:

·        Alt1: Use an indicator field (could be reusing an existing DCI field or introducing a new DCI field) in a DCI format 0_1/0_2 to inform which joint/UL TCI state(s) indicated by MAC-CE/DCI the UE shall apply to PUSCH transmission scheduled/activated by the DCI format 0_1/0_2

·        Alt2: PUSCH transmission scheduled/activated by a DCI format 0_1/0_2 follows the spatial domain transmission filter(s) used for the SRS resource(s) indicated by the DCI format 0_1/0_2

·        Alt3: Use an RRC parameter in a CORESET configuration to inform that the CORESET belongs to which CORESET group(s), and the indicated joint/UL TCI state(s) is associated with each CORESET group. When a scheduling/activation DCI format 0_1/0_2 is received in a CORESET group, the indicated joint/UL TCI state(s) associated with the CORESET group is applied to PUSCH transmission scheduled/activated by the DCI format 0_1/0_2

o   FFS: Details of CORESET group(s)

FFS: PUSCH transmission scheduled/activated by a DCI format 0_0 and Type-1 CG-PUSCH

Agreement

On unified TCI framework extension for S-DCI based MTRP, to inform the association with joint/UL TCI state(s) indicated by DCI/MAC-CE for PUCCH transmission, down-selection at least one alternative from the followings:

·        Alt1: Use RRC configuration to inform the association between the indicated joint/UL TCI state(s) and a PUCCH resource/ group

·        Alt2: Use RRC configuration to inform the association between a CORESET group and a PUCCH resource/group, and the indicated joint/UL TCI state(s) associated with the CORESET group applies to the PUCCH resource/group

·        Alt3: Use MAC-CE to inform the association between the indicated joint/UL TCI state(s) and a PUCCH resource/group

·        Alt4: Use DCI to inform the association between the indicated joint/UL TCI state(s) and a PUCCH resource/group

9.1.1.2       Two TAs for multi-DCI

R1-2205748         Enhancements to support two TAs for multi-DCI       FUTUREWEI

R1-2205817         On Utilization of Multiple TA         InterDigital, Inc.

R1-2205823         Discussion on two TAs for multi-DCI based on multi-TRP operation     TCL Communication Ltd.

R1-2205880         Study on TA enhancement for UL M-TRP transmssion             Huawei, HiSilicon

R1-2205919         TA enhancement for multi-DCI       ZTE

R1-2205982         Discussion on two TAs for multi-DCI based multi-TRP            Spreadtrum Communications

R1-2206025         Discussion on two TAs for multi-DCI-based multi-TRP operation         vivo

R1-2206210         Discussion of two TAs for multi-DCI UL transmission             Lenovo

R1-2206247         Two TAs for multi-DCI    Ericsson

R1-2206264         Two TAs for multi-DCI    OPPO

R1-2206376         Discussion on two TAs for UL multi-DCI for multi-TRP operation        CATT

R1-2206464         Discussion on two TAs for multi-DCI           NEC

R1-2206485         Discussion on two TAs for multi-DCI           Google

R1-2206571         On two TAs for multi-DCI Intel Corporation

R1-2206621         Discussion on two TAs for multi-TRP operation         Xiaomi

R1-2206668         Discussion on TA enhancement for multi-DCI based multi-TRP operation               Transsion Holdings

R1-2206811         Views on two TAs for m-DCI          Samsung

R1-2206867         Two TAs for multi-TRP/panel         LG Electronics

R1-2206895         Discussion on two TAs for multi-DCI           CMCC

R1-2206996         UL Tx Timing Management for MTRP Operation      MediaTek Inc.

R1-2207216         Supporting two TAs for multi-DCI based mTRP         Qualcomm Incorporated

R1-2207321         Views on two TAs for multi-DCI Uplink Transmissions           Apple

R1-2207394         Discussion on two TAs for multi-DCI           NTT DOCOMO, INC.

R1-2207451         Two TAs for multi-DCI    Sharp

R1-2207545         Two TAs for UL multi-DCI multi-TRP operation       Nokia, Nokia Shanghai Bell

R1-2207800        Moderator Summary on Two TAs for multi-DCI   Moderator (Ericsson)

From Tuesday session

Agreement:

For multi-DCI based multi-TRP operation with two TAs, study how to handle overlapping part between two UL transmissions associated with two TAs, where the study includes:

·        whether to introduce scheduling restriction in overlapping part

·        whether to introduce dropping rules

·        whether specification impact is needed, or if the issue can be handled via implementation

·        whether to allow overlapped transmission in case the UE supports STxMP transmission (if STxMP feature is agreed in NR Rel-18)

Agreement:

For multi-DCI based multi-TRP operation with two TAs, support configuring two TAGs belonging to a serving cell.

Agreement:

For multi-DCI based multi-TRP operation with two TAs, study the impact of two TAs for the following:

• RACH triggered by PDCCH order in intra-cell MTRP case
• RACH triggered by PDCCH order in inter-cell MTRP case
• Which might require RACH enhancement as well
• UE triggered RACH by CBRA or CFRA in RRC connected mode

Further details of enhancements needed (if any)

R1-2208016        Moderator Summary #2 on Two TAs for multi-DCI   Moderator (Ericsson)

From Thursday session

Agreement

For associating TAGs to target UL channels/signals for multi-DCI based multi-TRP operation, downselect one of the options in RAN1#110bis-e:

• Option 1: Associate TAG to TCI-state/spatial relation
• Option 2: Associate TAG to CORESETPoolIndex
• Option 3: Associate TAG to DL RS group. For a UL transmission, UE adopts the TAG associated with the DL RS group to which the PL RS of the UL transmission belongs.
• Option 4: Associate TAG to target UL channels/RSs directly for semi-static UL channels/RSs (e.g. P CSI PUCCH, P SRS, CG PUSCH), and further discuss how to associate TAG to dynamic UL channels/RSs(e.g. via associating TAG to CORESETPoolIndex additionally, etc.)

Agreement

For multi-DCI multi-TRP operation with two TAs, up to two n-TimingAdvanceOffset value per serving cell is supported.

9.1.2        CSI enhancement

Including CSI enhancement for high/medium UE velocities and coherent JT (CJT).

R1-2205818         CSI Enhancements for CJT and High Doppler Operations        InterDigital, Inc.

R1-2205881         CSI enhancement for coherent JT and mobility           Huawei, HiSilicon

R1-2205920         CSI enhancement for high/medium UE velocities and CJT       ZTE

R1-2205983         Discussion on CSI enhancement for high/medium UE velocities and coherent JT               Spreadtrum Communications

R1-2206026         Discussion on CSI enhancement for high-medium UE velocities and coherent JT vivo

R1-2206101         Discussion on CSI enhancement     Mavenir

R1-2206189         On CSI Enhancement        Google

R1-2206211         Discussion of CSI enhancement for high speed UE and coherent JT       Lenovo

R1-2206265         CSI enhancement for high/medium UE velocities and coherent JT         OPPO

R1-2206377         On Rel-18 CSI enhancements for high/medium UE velocities and coherent JT               CATT

R1-2206459         Discussion on CSI enhancement     NEC

R1-2206572         On CSI enhancements       Intel Corporation

R1-2206622         Discussion on CSI enhancements    Xiaomi

R1-2206812         Moderator summary on Rel-18 CSI enhancements     Moderator (Samsung)

R1-2206813         Summary of OFFLINE discussion on Rel-18 MIMO CSI          Moderator (Samsung)

R1-2206814         Views on CSI enhancements           Samsung

R1-2206868         Potential CSI enhancement for high/medium UE velocities and coherent JT         LG Electronics

R1-2206896         Discussion on CSI enhancement for high/medium UE velocities and  CJT               CMCC

R1-2206974         CSI enhancements for medium UE velocities and coherent JT Fraunhofer IIS, Fraunhofer HHI

R1-2206992         CSI enhancement MediaTek Inc.

R1-2207066         Discussion on CSI Enhancements for high/medium UE velocities and coherent JT               CEWiT

R1-2207217         CSI enhancements for high/medium UE velocities and Coherent-JT      Qualcomm Incorporated

R1-2207322         Views on Rel-18 MIMO CSI enhancement   Apple

R1-2207369         CSI Enhancements for CJT              AT&T

R1-2207395         Discussion on CSI enhancement     NTT DOCOMO, INC.

R1-2207452         CSI enhancement Sharp

R1-2207505         On CSI enhancements for Rel-18 NR MIMO evolution            Ericsson

R1-2207546         CSI enhancement for high/medium UE velocities and CJT       Nokia, Nokia Shanghai Bell

R1-2207603         Additional considerations on CSI enhancement for high/medium UE velocities and coherent JT (CJT)              Sony

R1-2206812        Moderator summary on Rel-18 CSI enhancements Moderator (Samsung)

From Monday session:

Agreement

·        For the Rel-18 Type-II codebook refinement for CJT mTRP with N_TRP>1 TRP/TRP-groups, support N_TRP={1, 2, 3, 4} with equal priority.

Agreement

For the Rel-18 Type-II codebook for CJT mTRP, support RI={1,2,3,4}.

Agreement

For the Rel-18 Type-II codebook refinement for CJT mTRP with N_TRP>1 TRP/TRP-groups, the following is supported:

• The CMR comprises K>1 NZP CSI-RS resources, where one resource corresponds to one TRP/TRP-group (i.e. K=N_TRP)
• Each of the CSI-RS resources has a same number of CSI-RS ports
• Note: The terms TRP and TRP-group are used for discussion purposes only (no spec impact is implied).

Agreement

For the Rel-18 Type-II codebook for CJT mTRP, support the following two modes:

·        Mode 1: Per-TRP/TRP-group SD/FD basis selection which allows independent FD basis selection across N TRPs / TRP groups. Example formulation (N = number of TRPs or TRP groups):

·        Mode 2: Per-TRP/TRP group (port-group or resource) SD basis selection and joint/common (across N TRPs) FD basis selection. Example formulation (N = number of TRPs or TRP groups):

• Striving for the two modes to share commonality in detailed designs such as parameter combinations, basis selection, TRP (group) selection, reference amplitude, W₂ quantization schemes.

·        FFS: Depending on the decision on SCI design, whether additional per-TRP/TRP-group amplitude scaling and/or co-phase is needed or not, and whether they are a part of W_2s

Agreement

For the Rel-18 Type-II codebook refinement for high/medium velocities, down-select one from the following codebooks structures:

• Alt2A: Doppler-domain basis commonly selected for all SD/FD bases, e.g.
• Note that  may be the identity as a special case
• Alt2B: Doppler-domain basis independently selected for different SD/FD bases
• Note that  may be the identity as a special case
• Alt3. Reuse Rel-16/17 (F)eType-II codebook with multiple  and a single  and  report.

Agreement

For the Rel-18 Type-II codebook refinement for high/medium velocities, on the DD/TD basis waveforms:

• Down-select or combine from the following Doppler-/time-domain basis waveforms:
• Alt1. Orthogonal DFT
• TBD (by RAN1#110bis): whether rotation is used or not
• FFS: identical or different rotation factors for different SD components
• Alt2. Identity (i.e. no Doppler-/time-domain compression)

·        FFS: Whether Doppler-/time-domain (DD/TD) basis vector length (N₄) is RRC-configured or reported by the UE

·        FFS: Whether the number of selected DD/TD basis vectors (for Alt1) is RRC-configured or reported by the UE

Agreement

On the CSI reporting and measurement for the Rel-18 Type-II codebook refinement for high/medium velocities, support the assumption of the UE-side prediction

• On the definition of UE-side prediction, down-select one from the following alternatives:
• Alt1. UE “predicting” channel/CSI after the slot with a reference resource
• Alt2. UE “predicting” channel/CSI after slot n (where the CSI is reported)
• Alt3. UE “predicting” channel/CSI after the slot where CSI-RS resides

Agreement

The Rel-18 TRS-based TDCP reporting comprises stand-alone auxiliary feedback information to enable refinement of CSI reporting configuration, and/or codebook configuration parameters, and/or (to be confirmed in RAN1#110) gNB-side CSI prediction

• Not conditioned on other UCI parameters
• Not reported together with CQI/PMI/RI/(CRI) associated with a codebook
• Note: This does not prevent TDCP reporting from being multiplexed with other UCI parameters on PUCCH and/or PUSCH
• Note: Aperiodic reporting is supported (per agreed Alt1 in RAN1#109-e)

R1-2207876        Moderator Summary#2 on Rel-18 CSI enhancements: Round 1        Moderator (Samsung)

From Wed session

Agreement

On the Type-II codebook refinement for CJT mTRP, down-select from the following TRP selection/determination schemes (where N is the number of cooperating TRPs assumed in PMI reporting) by RAN1#110bis-e:

·        Alt1. N is gNB-configured via higher-layer (RRC) signalling

o   The N configured TRPs are gNB-configured via higher-layer (RRC) signalling

o   Note: only one transmission hypothesis is reported

·      Alt2. N is UE-selected and reported as a part of CSI report where N{1,..., NTRP}

o   N is the number of cooperating TRPs, while NTRP is the maximum number of cooperating TRPs configured by gNB

o   In this case, the selection of N out of NTRP TRPs is also reported (FFS: exact reporting scheme)

o   FFS: Configuration of NTRP TRPs and the value of NTRP, whether explicit or implicit

o   Note: only one transmission hypothesis is reported. UE is not mandated to calculate CSI for multiple transmission hypotheses.

·        Alt3. The UE reports CSI corresponding to K transmission hypotheses

o   The N configured TRPs per hypothesis are gNB-configured via higher-layer (RRC) signalling

o   FFS: supported value(s) of K, and whether the K transmission hypotheses are gNB-configured or UE-reported

o   FFS: Whether the same N value or possibly different N values

·        Alt4. The UE reports CSI corresponding to K transmission hypotheses where N is UE-selected and reported as a part of CSI report where N{1,..., NTRP}

o   N is the number of cooperating TRPs per hypothesis, while NTRP is the maximum number of cooperating TRPs configured by gNB

o   In this case, the selection of N out of NTRP TRPs is also reported (FFS: exact reporting scheme)

o   FFS: Configuration of NTRP TRPs and the value of NTRP, whether explicit or implicit

o   FFS: Whether the same N value or possibly different N values

FFS: Whether S-TRP transmission hypothesis is also reported

Agreement

On the Type-II codebook refinement for CJT mTRP, regarding W2 quantization group and Strongest Coefficient Indicator (SCI) design, for each layer, down-select one from the following alternatives by RAN1#110bis-e:

·        Alt1. One group comprises one polarization across all TRPs/TRP-groups (C_group,phase=1, C_group,amp=2), one (common) SCI across all TRPs/TRP groups

·        Alt2. One group comprises one polarization for one TRP/TRP-group (C_group,phase=N, C_group,amp=2N), per-TRP/TRP-group SCI

o   FFS: Quantization of N strongest coefficients 

·        Alt3. One group comprises one polarization for one TRP/TRP-group with a common phase reference across TRPs/TRP-groups (C_group,phase=1, C_group,amp=2N)

o   FFS: SCI, per-TRP/TRP-group vs. one (common) SCI across all TRPs/TRP groups 

o   FFS: Quantization of N strongest coefficients

·        Alt4. For a selected TRP/TRP-group, one group comprises one polarization, and for remaining N-1 TRPs/TRP-groups, one group comprises one polarization across remaining N-1 TRPs/TRP-groups (C_group,amp=2+2=4), with a common phase reference across all of N TRPs/TRP-groups (C_group,phase=1)

o   FFS: The selected TRP/TRP-group

FFS: The need for “strongest” TRP/TRP-group indicator in addition to SCI(s)

Agreement

For the Rel-18 Type-II codebook refinement for high/medium velocities, support DD/TD (compression) unit (analogous to PMI sub-band for Rel-16 codebook) as a codebook parameter.

• FFS: whether this parameter is defined as a function of another parameter
• FFS: whether this is used for PMI only or PMI/CQI

Agreement

On the CSI reporting and measurement for the Rel-18 Type-II codebook refinement for high/medium velocities assuming the UE-side prediction, on the definition of UE-side prediction, down-select one from the following alternatives by RAN1#110bis-e:

• Alt1. UE “predicting” channel/CSI after the slot with a reference resource
• Alt2. UE “predicting” channel/CSI after slot n (where the CSI is reported)
• Alt3. UE “predicting” channel/CSI after the slot where CSI-RS resides

R1-2207978        Moderator Summary#3 on Rel-18 CSI enhancements: Round 2        Moderator (Samsung)

Agreement

For the Rel-18 Type-II codebook for CJT mTRP based on the Rel-16 Type-II codebook, SD basis and FD basis are separate, each fully reusing the legacy Rel-16 DFT-based design.

Agreement

The Rel-18 Type-II codebook for CJT mTRP comprises refinement of the following codebooks:

• Refinement of the Rel-16 eType-II regular codebook
• Refinement of the Rel-17 FeType-II port selection (PS) codebook, based on the same design details as the refinement of the Rel-16 eType-II regular codebook, except for the supported set of parameter combinations

Strive to maintain as much commonality between the Rel-16 and Rel-17 codebook enhancements to minimize workload.

Vivo and Lenovo raised concerns on the workload due to this agreement.

Agreement

On the CSI reporting and measurement for the Rel-18 Type-II codebook refinement for high/medium velocities, when UE-side prediction is assumed, down-select one from the following alternatives by RAN1#110bis-e:

• Alt1.B:  l ≥ n_ref
• n_ref (a CSI reference resource slot) as boundary

• Alt2.B: l ≥ n
• n (report slot) as boundary

Agreement

For the Rel-18 TRS-based TDCP reporting, down select one of the following alternatives by RAN1#110bis-e:

·        AltA. Based on Doppler profile

o   E.g., Doppler spread derived from the 2^nd moment of Doppler power spectrum, average Doppler shifts, Doppler shift per resource, maximum Doppler shift, relative Doppler shift, etc

·        AltB. Based on time-domain correlation profile

o   E.g. Correlation within one TRS resource, correlation across multiple TRS resources

o   Note: The correlation over one or more lags of TRS resource may be considered.  The lags may be within one TRS burst or different TRS bursts

·        AltC: CSI-RS resource and/or CSI reporting setting configuration parameter(s) to assist network

o   E.g. gNB configures UE with multiple choices on what to assist (e.g. two or more CSI-RS/report periodicities, or precoding schemes depending mainly on UE velocity), then UE report according to configuration; parameters correspond to CSI reporting periodicity, codebook type, etc.

Note: Different alternatives may or may not apply to different use cases.

Agreement

For the Rel-18 TRS-based TDCP reporting, the use case of “aiding gNB-side CSI prediction” is refined to “aiding gNB implementation in CSI prediction for TDD”.

9.1.3        Reference signal enhancement

9.1.3.1       Increased number of orthogonal DMRS ports

Including increasing orthogonal DMRS ports for UL/DL MU-MIMO and 8 Tx UL SU-MIMO.

R1-2205749         On increasing the number of orthogonal DM-RS ports for MU-MIMO               FUTUREWEI

R1-2205819         Enhanced Capacity DMRS               InterDigital, Inc.

R1-2205882         Enhancements on DMRS in Rel-18 Huawei, HiSilicon

R1-2205921         DMRS enhancement for UL/DL MU-MIMO and 8 Tx UL SU-MIMO   ZTE

R1-2205984         Discussion on increased number of orthogonal DMRS ports    Spreadtrum Communications

R1-2206027         Discussion on DMRS enhancements             vivo

R1-2206106         Discussions on increased number of orthogonal DMRS ports   New H3C Technologies Co., Ltd.

R1-2206190         On DMRS Enhancement   Google

R1-2206212         Discussion of increased number of orthogonal  DMRS ports    Lenovo

R1-2206266         DMRS enhancement for Rel-18 MIMO         OPPO

R1-2206378         On DMRS enhancements  CATT

R1-2206460         Discussion on increased number of orthogonal DMRS ports    NEC

R1-2206573         Discussion on DMRS enhancement Intel Corporation

R1-2206623         Discussion on DMRS enhancement Xiaomi

R1-2206815         Views on DMRS enhancements      Samsung

R1-2206869         Increased number of orthogonal DMRS ports              LG Electronics

R1-2206897         Discussion on increased number of orthogonal DMRS ports    CMCC

R1-2206966         Increased number of orthogonal DMRS ports              Fraunhofer IIS, Fraunhofer HHI

R1-2206993         Increased number of orthogonal DMRS ports              MediaTek Inc.

R1-2207135         On DMRS enhancement in Rel-18  Ericsson

R1-2207218         Design for increased number of orthogonal DMRS ports          Qualcomm Incorporated

R1-2207323         Views on supporting increased number of orthogonal DMRS ports        Apple

R1-2207396         Discussion on DMRS enhancements             NTT DOCOMO, INC.

R1-2207453         Increased number of orthogonal DMRS ports              Sharp

R1-2207547         Rel-18 UL and DL DMRS Enhancements     Nokia, Nokia Shanghai Bell

R1-2207715        FL summary on DMRS#1              Moderator (NTT DOCOMO)

From Tuesday session

Working Assumption

·        To increase the number of DMRS ports for PDSCH/PUSCH, support at least Opt.1 (introduce larger FD-OCC length than Rel.15 (e.g. 4 or 6)).

o   FFS: FD-OCC length for Rel.18 DMRS type 1 and type 2.

o   FFS: Whether it is needed to handle potential performance issues of Opt 1. For example, study if there is performance loss in case of large delay spread scenario. If needed, how (e.g. additionally support other options).

Ericsson objected to make the above as an agreement – their preference was for no additional DMRS symbols – fine to take it as working assumption and let the work progressing further

R1-2207716        FL summary on DMRS#2              Moderator (NTT DOCOMO)

From Wed session

Agreement

• For enhanced FD-OCC length for DMRS of PDSCH/PUSCH, support the following FD-OCC length:
• For Rel.18 DMRS type 1, down select from the following in RAN1#110bis-e:
• Opt.1-1: Length 6 FD-OCC is applied to 6 REs of DMRS within a PRB within an CDM group
• Opt.1-2: Length 4 FD-OCC is applied to 4 REs of DMRS within a PRB or across consecutive PRBs within an CDM group
• For Rel.18 DMRS type 2:
• Length 4 FD-OCC is applied to 4 REs of DMRS within a PRB within an CDM group
• FFS: Support of length 6 FD-OCC

Agreement

• Support MU-MIMO between Rel.15 DMRS ports and Rel.18 DMRS ports.
• For MU-MIMO by different CDM groups, no MU-MIMO scheduling restriction of PUSCH/PDSCH (i.e. MU-MIMO between Rel.15 UE and Rel.18 UE is allowed).
• For MU-MIMO within a CDM group, study whether and how to support MU-MIMO between Rel.15 DMRS ports and Rel.18 DMRS ports for PDSCH.
• Note: the study includes MU-MIMO between Rel.15 UE and Rel.18 UE, and between Rel.18 UEs.
• Note: PUSCH above is CP-OFDM waveform.

Agreement

• For support of more than 4 layers SU-MIMO PUSCH, study the following potential enhancements for PTRS-DMRS association.
• Whether to support more than 2-port UL PTRS.
• Whether to increase the DCI size of PTRS-DMRS association field in DCI format 0_1/0_2.

R1-2208005        FL summary#3 on DMRS              Moderator (NTT DOCOMO)

From Thursday session

Agreement

For increased DMRS ports for enhanced FD-OCC, study whether/how to support DCI based switching between DMRS port(s) associated with length 2 FD-OCC and DMRS port(s) associated with length M FD-OCC (where M > 2).

Agreement

For > 4 layers PUSCH, support rank = 5,6,7,8 for both DMRS type 1/2, and for both single-symbol/double-symbol DMRS.

9.1.3.2       SRS enhancement targeting TDD CJT and 8 TX operation

R1-2205750         SRS enhancements for TDD CJT and 8TX operation FUTUREWEI

R1-2205820         On SRS Enhancements for CJT and 8TX UEs             InterDigital, Inc.

R1-2205883         SRS enhancement for TDD CJT and UL 8Tx operation in Rel-18           Huawei, HiSilicon, LG Uplus

R1-2205922         SRS enhancement targeting TDD CJT and 8 TX operation       ZTE

R1-2205985         Discussion on SRS enhancement targeting TDD CJT and 8 TX operation               Spreadtrum Communications

R1-2206028         Discussion on SRS enhancement    vivo

R1-2206191         On SRS Enhancement       Google

R1-2206213         Discussion of SRS enhancement     Lenovo

R1-2206267         SRS enhancement targeting TDD CJT and 8 TX operation       OPPO

R1-2206379         On SRS enhancement for R18         CATT

R1-2206419         Views on SRS configuration targeting TDD CJT and 8 TX operation    KDDI Corporation

R1-2206461         Discussion on SRS enhancement    NEC

R1-2206574         Discussion on SRS enhancement in Rel-18   Intel Corporation

R1-2206624         Discussion on SRS enhancements   Xiaomi

R1-2206816         Views on SRS enhancements          Samsung

R1-2206870         SRS enhancement targeting TDD CJT and 8 TX operation       LG Electronics

R1-2206898         Discussion on SRS enhancement targeting TDD CJT and 8 TX operation               CMCC

R1-2207067         Discussion on SRS Enhancements for 8Tx Operation CEWiT

R1-2207219         SRS enhancement for TDD CJT and 8 Tx operation   Qualcomm Incorporated

R1-2207324         Views on Rel-18 MIMO SRS enhancement  Apple

R1-2207397         Discussion on SRS enhancement    NTT DOCOMO, INC.

R1-2207454         SRS enhancement targeting TDD CJT and 8 TX operation       Sharp

R1-2207499         On SRS enhancements targeting TDD CJT and 8 TX operation              Ericsson

R1-2207548         SRS enhancement for TDD CJT and 8Tx operation    Nokia, Nokia Shanghai Bell

R1-2207604         Considerations on precoded SRS     Sony

R1-2207855        FL Summary #1 on SRS enhancements     Moderator (FUTUREWEI)

From Tuesday session

Agreement:

For Rel-18 reference signal enhancements, support and specify the following features (the agreed WID scopes apply):

• SRS enhancement to manage inter-TRP cross-SRS interference targeting TDD CJT via SRS capacity enhancement and/or interference randomization;
• RAN1 should strive to minimize the number of schemes supported in Rel-18
• SRS enhancements to enable 8 Tx UL operation and 8T8R SRS for DL operation.
• Target usage includes antenna switching, codebook/non-codebook based SRS

Proposal 4.2-2:

For 8 Tx SRS, support both

• 8 ports in one OFDM symbol
• 8 ports in multiple OFDM symbols where different ports are mapped to different symbols

R1-2207856        FL Summary #2 on SRS enhancements     Moderator (FUTUREWEI)

From Wed session

Agreement:

For 8 Tx SRS, at least support

·        8 ports in 1 SRS resource for ‘antennaSwitching’;

o   FFS 8 ports in one or multiple SRS resources for ‘codebook’

Above does not imply support for 8 ports in one or multiple OFDM symbols

Agreement:

For the maximum number of SRS resource sets for SRS with 8T8R with ‘antennaSwitching’, keep the existing value of the maximum number of SRS resource sets (as provided in Rel-17 antenna switching nTnR).

R1-2208014        FL Summary #3 on SRS enhancements     Moderator (FUTUREWEI)

From Thursday session

Agreement

For an 8-port SRS resource in an SRS resource set with usage antennaSwitching (i.e., for 8T8R antenna switching), the 8-port SRS resource is transmitted in at least one OFDM symbol.

·        FFS: the resource transmitted in multiple OFDM symbols where different ports are mapped to different symbols.

Agreement

For SRS resource set(s) with usage ‘nonCodebook’ support 8 1-port SRS resources in one or multiple OFDM symbols.

·        Note: The maximum number of simultaneous SRS resources is determined via UE-capability signalling.

Final summary in R1-2208015.

9.1.4        Enhanced uplink transmission

9.1.4.1       UL precoding indication for multi-panel transmission

R1-2205821         Discussion on Uplink Multi-panel Transmission         InterDigital, Inc.

R1-2205884         Discussion on UL precoding indication for multi-panel transmission     Huawei, HiSilicon

R1-2205923         Enhancements on UL precoding indication for multi-panel transmission              ZTE

R1-2205986         Discussion on UL precoding indication for multi-panel transmission     Spreadtrum Communications

R1-2206029         Discussion on UL precoding indication for multi-panel transmission     vivo

R1-2206111         Considerations on UL for multi-panel transmission    Sony

R1-2206162         Discussion on UL precoding indication for multi-panel transmission     Fujitsu

R1-2206192         On Simultaneous Multi-Panel Transmission Google

R1-2206214         UL precoding indication for multi-panel transmission Lenovo

R1-2206268         Transmission scheme and UL precoding indicaton for multi-panel transmission               OPPO

R1-2206380         Discussion on UL precoding indication for multi-panel transmission     CATT

R1-2206465         Discussion on UL precoding indication for multi-panel transmission     NEC

R1-2206575         UL precoding indication for multi-panel transmission (STxMP)             Intel Corporation

R1-2206625         Enhancements on multi-panel uplink transmission      Xiaomi

R1-2206817         Views on UL precoding indication for STxMP            Samsung

R1-2207693         UL precoding indication for multi-panel transmission LG Electronics    (rev of R1-2206871)

R1-2206899         Discussion on UL precoding indication for multi-panel transmission     CMCC

R1-2206997         Simultaneous transmission across multiple UE panels MediaTek Inc.

R1-2207112         UL precoding indication for multi-panel transmission Ericsson

R1-2207145         On UL precoding indication for simultaneous multi-panel transmission Fraunhofer IIS, Fraunhofer HHI

R1-2207220         Simultaneous multi-panel transmission         Qualcomm Incorporated

R1-2207325         Views on UL precoding indication for multi-panel simultaneous PUSCH transmissions       Apple

R1-2207761         Discussion on multi-panel transmission        NTT DOCOMO, INC.       (rev of R1-2207398)

R1-2207455         Views on UL multi-panel transmission         Sharp

R1-2207549         Precoder Indication for Multi-Panel UL Transmission Nokia, Nokia Shanghai Bell

R1-2207698        Summary #1 on Rel-18 STxMP    Moderator (OPPO)

R1-2207699        Summary #2 on Rel-18 STxMP    Moderator (OPPO)

From Thursday session

Working assumption

Support the following schemes for STxMP PUSCH transmission in single-DCI based mTRP system in Rel-18:

• SDM scheme
• In RAN1#110bis-e, RAN1 will only consider SFN based transmission scheme to support in addition to the above. Decision to support or not to be made in RAN1#110bis-e.
• FFS: FDM-A scheme
• FFS: FDM-B scheme
• FFS: SFN-based transmission scheme

For schemes other than SDM, final decision to support or not will be made in RAN1#110bis-e.

Agreement

For single-DCI based STxMP PUSCH SDM scheme, support the layer combinations of {1+1, 1+2, 2+1 and 2+2} for single CW case.

• FFS on layer combinations of {1+3} and {3+1} considering the performance gain, system/UE complexity, specification efforts, etc.
• FFS: the option of using layer combination of 0+n and n+0 for dynamic switch between single-panel and STxMP (n=1 or 2, 3 or 4).
• This applies to SDM with 1 CW at least.

Agreement

To enhance the DMRS port indication for SDM scheme of STxMP PUSCH transmission in single-DCI based mTRP system, study the following aspects:

• Whether the indicated DMRS ports can be in different or same CDM group?
• How to determine the port partition among PUSCH layers.
• How to map DMRS ports with PUSCH layers from different panels.
• Whether to use one DCI field or two DCI fields for DMRS port indication
• How to indicate layer combination that is used to partition DMRS port partition among PUSCH layers.
• Other aspects are not precluded.

Agreement

Study and evaluate STxMP PUCCH based on the following:

·        For single-DCI based STxMP PUCCH transmissions, companies to provide the detailed description of the scheme being evaluated along with evaluation results in contribution.

·        For multi-DCI based STxMP PUCCH transmissions, transmitting two PUCCH resources with independent UCI payload to different TRPs with different UE panels that are fully or partially overlapping in time domain and partially/fully/non-overlapping in frequency domain can be considered.

·        Note: Companies can reuse the EVM assumptions of Rel-18 STxMP as agreed in RAN1#109-e (other than the parameters that are specific to PUSCH) as well as Rel-17 EVM for PUCCH as agreed in RAN1#102-e (PUCCH format, # of RBs/symbols, UCI payload, and Frequency hopping as shown below).

o   Baseline scheme can be Rel-15 PUCCH or Rel-17 mTRP PUCCH repetition.

9.1.4.22       SRI/TPMI enhancement for enabling 8 TX UL transmission

To support up to 4 or more layers per UE in UL targeting CPE/FWA/vehicle/industrial devices.

R1-2205822         SRI/TPMI Enhancement for 8TX UE            InterDigital, Inc.

R1-2205885         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               Huawei, HiSilicon

R1-2205924         SRI/TPMI enhancement for enabling 8 TX UL transmission    ZTE

R1-2205987         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               Spreadtrum Communications

R1-2206030         Discussion on enabling 8 TX UL transmission            vivo

R1-2206112         Discussion on enhancement for 8Tx UL transmission Sony

R1-2206193         On SRI/TPMI Indication for 8Tx Transmission          Google

R1-2206215         SRI/TPMI enhancement for enabling 8TX UL transmission     Lenovo

R1-2206269         SRI TPMI enhancement for 8 TX UL transmission    OPPO

R1-2206381         On codebook and SRI/TPMI enhancement for UL 8 TX            CATT

R1-2206462         Discussion on SRI/TPMI enhancement         NEC

R1-2206576         Discussion on enhancement for 8Tx UL transmission Intel Corporation

R1-2206626         Enhancements on 8Tx uplink transmission   Xiaomi

R1-2206818         Views on TPMI/SRI enhancements for 8Tx UL transmission   Samsung

R1-2206872         SRI/TPMI enhancement for enabling 8 TX UL transmission    LG Electronics

R1-2206900         Discussion on SRI/TPMI enhancement for enabling 8 TX UL transmission               CMCC

R1-2206994         SRI/TPMI enhancement for enabling 8 TT UL transmission    MediaTek Inc.

R1-2207163         SRI/TPMI Enhancement for Enabling 8 TX UL Transmission Ericsson

R1-2207221         Enhancements for 8 Tx UL transmissions     Qualcomm Incorporated

R1-2207326         Views on SRI/TPMI enhancement for enabling 8 TX UL transmission  Apple

R1-2207399         Discussion on 8 TX UL transmission            NTT DOCOMO, INC.

R1-2207456         Views on 8 TX UL transmission     Sharp

R1-2207550         UL enhancements for enabling 8Tx UL transmission Nokia, Nokia Shanghai Bell

R1-2207725        FL Summary on SRI/TPMI Enhancements; First Round    Moderator (InterDigital)

From Monday session

Agreement

·        8TX PUSCH is supported in Rel-18

Agreement

For a 8TX PUSCH, at least support

• Ng=1, 2, 4

Note: The above does not restrict the Ng for the non-coherent case

Agreement

For evaluation purpose of codebook alternatives when a precoder based on Rel-15 DL Type I is used, following oversampling ratios are assumed

·        (O1, O2) = (1,1), (2,1), (2,2)

·        Note: Other values may be used and reported by companies

·        Note: When deciding the supported O1, O2 combination, the signalling overhead, performance, UE complexity, etc should be considered

Agreement

RAN1 further studies Alt1b and Alt2a for down-selection of one of the two in RAN1 meeting #110b-e.

• Transmission using one or multiple precoders corresponding to one or multiple SRS resources can be studied as part of the above alternatives.

R1-2207726        FL Summary on SRI/TPMI Enhancements; Second Round Moderator (InterDigital)

From Wed session

Agreement

Support up to X layers for codebook and non-codebook UL transmission for 8TX UE where X=4, 8 is determined based on separate UE capability

• For uplink transmission with rank<=4, single CW is supported
• For uplink transmission with rank>4, whether single or dual CW is used will be decided in RAN1 meeting #110b-e

The above applies only with regards to the work scope of this agenda item.

Agreement

For SRS configuration for non-codebook UL transmission for an 8TX UE, down-select from

• Alt1: A single SRS resource set configured with up to 8 single-port SRS resources
• Alt2: Up to two SRS resource sets, each configured with up to 4 single-port SRS resources
• Alt3: Support both alternatives.

R1-2208012        FL Summary on SRI/TPMI Enhancements; Third Round  Moderator (InterDigital)

From Thursday session

Agreement

Study low overhead solutions for SRI and/or transmitter precoder matrix indication for codebook-based, and SRI indication for non-codebook-based UL transmission by an 8TX UE,

·    FFS using single or separate (exiting or new) fields for the indication, other solutions are not precluded.

·    Note: Low overhead schemes for study include those using Rel-15 SRI/TPMI indication mechanisms